Delete Unused Code Instead of Commenting It Out

While reading The Art Of Unit Testing, I was stuck on a particular sentence:

You should then remove (not comment out) the invalid requirement and its tests.

This made me think about something that happen very often: when modifying code, we are tempted to comment out some of the code that is not used anymore.

I suppose that we do that for two reasons:

  1. If we need to get something from that old code, it is easy to get it back as it is still there.
  2. Deleting code is a very hard psychological action for a developer. In Code Complete (well, I think it’s in there, I don’t have a copy here to confirm), Steve says that for a developer, throwing away code that he wrote is very difficult.

However, remember that as your source code is under version control (it is, right? If not, read this and this), so you should not worry about deleting stuff. If you accidentally delete something that you later want to get back, use undo or have a look at the previous version of the file. If some code is not used anymore, just get rid of it.

Comments should be there to help the next developer to understand the code. If you comment out a line of code but leave it because it makes the code more clear, that’s fine. Commenting a whole method that is not used anymore doesn’t help to understand the code, so it should be deleted.

Constant in Eclipse and in Visual Studio

Java naming conventions states that constants, declared as static and final, must be named all uppercase. Eclipse will automatically turn these guys in blue and italic. Here is an example of what it will look like in Eclipse:

public class Sandbox {
    public static final String CONSTANT_VALUE = "Hello World!";
    public static void main(String[] args) {

That’s pretty neat. You cannot miss a constant, even if it is not fully qualified (it has to be if it is from another class, of course).

According to Microsoft’s naming conventions, constants in C# (that use the const keyword, being compile time constants) have to be named using Pascal Case. Visual Studio doesn’t color it any special way, meaning that if it is not qualified, you cannot know if it is a constant, a propertie, a variable…

Here is what it looks like:

class Sandbox
    const String ConstantValue = "Hello World!");

    static void Main(string[] args)

I find this a bit disturbing, as constant should always be easy to recognize. Well, at least that what I think. I was not able to find any option in Visual Studio to change this. A good start is to always fully qualify constants, in this case using Sandbox.ConstantValue (same advice goes for this keyword, I always use it, even when unnecessary).

You can find some more details on this subject here on stackoverflow.