Hot answers tagged

233

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


211

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


205

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


131

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


116

Firstly, magic values are avoided in programming by using variables or constants. CSS does not support variables, so even if magic values were frowned on, you don't have much of a choice (except using a preprocessor as SASS, but you wouldn't do that for a single snippet). Secondly, values might not be as magic in a domain specific language like CSS. In ...


107

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


102

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


98

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


93

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


79

It's acceptable because these formats are not code, but data. If you were to remove all the "magic numbers," you would essentially duplicate every label, and end up with ridiculous looking files like: mainkite_width = 200px ... .mainkite { width: mainkite_width; ... Every time you needed to change some data, you would need to look in two places. ...


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


47

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


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


42

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


42

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


40

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.


40

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


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

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.


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.


34

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


31

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


30

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


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


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


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

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


27

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



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