Tag Info

Hot answers tagged

206

In layman's words: The important thing is not the numbers of lines but the readability of the code. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler) In the examples you gave, the second one is definitively easier to read. Source code is for people to read. Besides, ...


195

Most of your reasons to keep it are utterly irrelevant, put simply. If the code isn't used, throw it away- any benefit involved in keeping it can be trivially derived from source control. At most, leave a comment saying which revision to find it in. Quite simply, the sooner you cut the code, the sooner you don't have to waste time maintaining it, compiling ...


183

Protected variables should be avoided because: They tend to lead to YAGNI issues. Unless you have a descendant class that actually does stuff with the protected member, make it private. They tend to lead to LSP issues. Protected variables generally have some intrinsic invariance associated with them (or else they'd be public). Inheritors then need to ...


106

You should strive to become irreplaceable not by writing code noone else understands, but by gathering more experience and knowledge than others. The former way makes you a developer everyone tries to avoid working with, as they will fear and loath maintaining code you wrote. The latter way you become a sought out team member, whom managers want to have in ...


97

It depends, and your example is not useful in making the decision. While fewer lines of code are not always better (at some point it leads to obfuscation), they usually are, simply because there's fewer things to keep track of when trying to understand the code. In your specific example: If the names of the intermediate values actually convey meaning that ...


71

I believe you are looking at the problem the wrong way - you are missing a great opportunity of teaching the juniors how to write better code. If you habitually re-write their code, you might give your juniors the impression that you don't value their work, which will lower their morale, and not help them code better the next time. A better approach, I ...


46

Sounds like a good habit to me. First rule in coding is to make it work. Once you've done that, clean up your code and make it neat, understandable and simpler if you can. However - if you are spending a lot of time over designing your solution and wasting a lot of time creating stuff that doesn't need to exist, that's possibly a bad habit - like if you ...


45

If you are going to manipulate organizations or people so transparently they'd better be stupid or in a jam that leaves them no other choice. A well run software development shop would look at your obscure code and missing documentation and simply fire you before you could do much damage. If they're poorly run, or unable to get any other developers to work ...


41

Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say `(x++ && false) || y += 2` instead of `x++; y += 2` ...


39

All of the reasons to remove it stand. Reasons to keep it: Can be used as reference It may be useful sometime It may have been written to 'round-out' the functionality for a class All of these reasons to keep it will be managed by source control. Remove it from the live code and you will be able to retrieve it if/when it's needed.


38

In general: use it. Write a test for your function, a real world test. Something you would actually like to do with that function. And see in what order you did put those down. Unless you already have (or know of) some functions that do something similar. In that case: conform to what they do already, at least for the first arguments. e.g. Do they all ...


37

The term is not performance related, at least not anywhere I have seen it used. It is specifically about code that is not maintained well and becomes... dirty... rotten. It is about code whose design has not been updated as changes were made and is difficult to read and understand.


36

It's really the same reason you avoid globals, just on a smaller scale. It's because it's hard to find everywhere a variable is being read, or worse, written to, and hard to make the usage consistent. If the usage is limited, like being written in one obvious place in the derived class and read in one obvious place in the base class, then protected ...


33

I think my best definition of Clean Code would be: Code that I can skim, and immediately understand it's purpose and how it works. That seems simple enough, but alot of goes into fulfilling that goal, such as: Good naming of types, methods, and locals. Avoiding "clever tricks". Not putting too much in one statement / line. Adhering to a shared coding ...


32

For a start the rule says "probably", so it doesn't always apply. The second point I see here is that if you have to declare one of the three, that's because it's doing something special like allocating memory. In this case, the others wouldn't be empty since they would have to handle the same task (such as copying the content of dynamically allocated ...


32

Just the single field being used for the lookup. The caller doesn't have a Foo, it's trying to get one. Sure, you can make a temporary Foo with all other fields left blank, but that only works for trivial data structures. Most objects have invariants that would be violated by the mostly-empty-object approach, so avoid it.


30

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates) Of course, fewer lines are not always better. But in my experience, fewer lines are often better than more lines in terms of readability and maintainability. There are exceptions, of course, and your example might be one such exception. ...


29

Clean Code: The code which doesn't make me want to kill the author. I can accept different coding styles, but if I can't read the damn thing, I will hate the damned author. Update: Sometimes, it is possible to discover that I am the damned author :)


29

I have said this before and will say it again "working code is more valuable than pretty code". If you change code the chances are high that you will change its behavior, if this is tested code then you have just invalidated all the testing effort, and will need to repeat the tests. By all means encourage your juniors to write clean understandable code, ...


28

Use an auto-formatter. If you really are spending that much time manually editting the code, I would be willing to guess you are not very challenged/bored, because there is absolutely no reason for it. Ctrl+K, Cntrl+D in VS will format an entire document. You can use something like Style Cop if you want something a bit more heavyweight. It is good to have ...


27

The simple answer is that you really can't prevent code duplication. You can however "fix it" through a difficult continuous repetitive incremental process that boils down into two steps: Step 1. Start writing tests on legacy code (preferably using a testing framework) Step 2. Rewrite/refactor the code that is duplicated using what you've learnt from the ...


26

Always err on the side of a readable client ... GetWebDriver("IE", true) or GetRemoteWebDriver("IE") It seems self-evident to me which one is easier to read. Of course, another option would be GetWebDriver("IE", DriverType.Remote) Which is equally readable, but I wouldn't go down that road unless there are likely to be more than two options.


23

In my experience, making new code clean is actually not that difficult. Typically you have a single clean concept in your mind about what the code is supposed to do, how to implement it etc. so it is fairly easy to arrange the code to reflect this one thing clearly (a least according to one's current understanding - returning to the same piece of code 6 ...


23

My experience: A piece of code longer than 20 lines, written as a proof-of-concept, will not get re-written when the concept thus proved is needed, but rather bent to somewhat fit the needs of the production code. Usually, this goes with the promise to re-write it later, when there is time to do it all properly. However, this time never comes, so this ...


23

From experience: TDD does not necessarily lead to good design. It's possible and really easy to get poorly designed program using TDD. TDD is just a tool to help us design faster using refactoring, it will never make the design of the program appear magically. TDD is a design help tool. The quality of the design you will get out of TDD depend largely on ...


21

I can give you one example from my experience. About 10 or 12 years ago I inherited an application from a team of developers that ended up leaving the company (too long to get into here...). The system was a large home-grown middleware report generation system. It ran every week night and generated about 2 dozen Excel reports for senior executives of a ...


20

Unreferenced code is the same as keeping those batteries that are kinda, sorta flat just in case you need them one day for a torch. As long as you're using some kind of version control I'd say trash it out of the live code and use the versioning history in case it turns out to be useful.


20

Prioritize. First things first. Focus on what matters. Your priorities may vary, but in general you should care about: Correct code Maintainable code Clean code Simple, elegant code Efficient code Maybe in that order. However, the first point is the most important. Without it, code is useless. What do you do with a program which doesn't work correctly? ...


20

My answer may be little off topic, but this method works for me. Before you even start programming you have to think: what kind of structures I need to solve a problem, and what kind of algorithms. Often you will find that solution already exist and that you only have to implement it into your project*. Never try to reinvent a wheel - if you need ...



Only top voted, non community-wiki answers of a minimum length are eligible