Tag Info

Hot answers tagged

210

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, ...


201

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 ...


196

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 ...


129

You have an invariant: Only a single view (out of 3) is ever active (and visible). Then, I suggest that you provide a function to switch the activity and visibility of ALL views at once: [setActiveView viewID:2] This function will: check if the view is already active, avoiding unnecessary work set the view as active, and visible set the other 2 ...


105

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 ...


92

As others have said, there's a difference between API-documenting comments and in-line comments. From my perspective, the main difference is that an in-line comment is read alongside the code, whereas a documentation comment is read alongside the signature of whatever you're commenting. Given this, we can apply the same DRY principle. Is the comment saying ...


78

The Robert C. Martin quote is taken out of context. Here is the quote with a bit more context: Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation. Comments are not ...


76

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 ...


47

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 ...


44

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 ...


43

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` ...


41

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 ...


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

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 ...


37

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 ...


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.


37

I prefer 2, but I might go for a small adjustment to it: obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE ); To me the parentheses makes the line easier to parse and makes it clear at a glance that you are assigning the result of a comparison, and not performing a double assignment. I'm not sure why that is (as off-hand I can't think of a ...


34

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.


32

There is a difference between commenting your code and documenting your code. Comments are needed to maintain the code later, that is change the code itself. Comments may indeed be perceived as problematic. The extreme point would be to say that they always indicate a problem, either within your code (code too difficult to understand) or within the ...


30

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, ...


30

Add the title to the parameters of the printf: char* title1; switch(gender1){ case 'M': title1 = "Sir"; break; case 'W': title1 = "Madam"; break; case ...etc. } char* title2; switch(gender2){ case 'M': title2 = "Sir"; break; case 'W': title2 = "Madam"; break; case ...etc. ...


29

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 ...


29

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. ...


28

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.


24

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 ...


24

As with all these things it depends. If you aren't going to use the result of your call to ValidateCredentials then there's no need (other than for debugging purposes) to store the result in a local variable. However, if it makes the code more readable (and hence more maintainable) to have a variable go with that. The code isn't going to be measurably less ...


24

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 ...



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