Let’s talk about some of the more annoying habits many programmers have: the inability to delete code. Code is kept around as if their life depends on it, even when its purpose is long gone. They do all possible things so they don’t have to delete anything. They comment code out, put unreachable conditions around it or throw files out of a solution (in Visual Studio), just to keep the file in a place where no one is looking. All this is clutter and needs to go away.

Exceptions

This post is not about examples in a living documentation or conditional comments to run code only in a specific version of IE. Both of them have a purpose and can stay.

Unreachable Code

Some developers find it a great solution to put their no longer needed code inside an unreachable execution branch. All they need to do is to write an if-statement with false as its condition around their code:

if(false) { var i = 0; var j = 10; var sum = 0; // many more lines of code } 1 2 3 4 5 6 7 if ( false ) { var i = 0 ; var j = 10 ; var sum = 0 ; // many more lines of code }

The most annoying problem with this “solution”: That code still has references to your classes and methods. If you change the method signature, you must update this unreachable code as well. If this behaviour is repeated often enough, then whole classes are only used in those unreachable blocks. But without a simple way to detect that, you must keep maintaining code that never will be run. What a waste of time!

No Longer Needed Code

Just as annoying are blocks of commented out code. The developer changes the logic and has now code he no longer needs. It was hard to write so better keep it around:

public int X() { var i = 0; var j = 10; var sum = 0; //for (; i < j; i++) /*{ sum += i;*/ //} sum = i + j; return sum; } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public int X ( ) { var i = 0 ; var j = 10 ; var sum = 0 ; //for (; i < j; i++) /*{ sum += i;*/ //} sum = i + j ; return sum ; }

The problem with those blocks is that they slow you down when you try to read the method. The commented out code is often right in the middle of some complex code. Otherwise one could ignore it, but so you have to carefully check if the whole block is commented out or if there are some parts that are still in use.

But it gets worse. Some developers found out that delimited comments allow you to only comment out parts of a line:

public int Y(int a, int b, /*int c, */ bool d, bool c) { if (a > b && c /*> a*/ || d /*< b*/) { a = b; } return a; } 1 2 3 4 5 6 7 8 9 public int Y ( int a , int b , /*int c, */ bool d , bool c ) { if ( a > b && c /*> a*/ || d /*< b*/) { a = b; } return a ; }

The switch from commented out code, code in use and back to commented out is unfortunately not only an example. This style makes it nearly impossible to reason about the code and whenever you try to make a change you have to carefully inspect what parts are needed and which are not.

A Simple Solution

To all those bad examples there is one single simple solution: Delete that code. Don’t comment it out, delete it. You no longer need it and getting rid of it makes your code base simpler.

The example from above is much simpler to understand when the commented out parts are gone:

public int Y(int a, int b, bool d, bool c) { if (a > b && c || d ) { a = b; } return a; } 1 2 3 4 5 6 7 8 9 public int Y ( int a , int b , bool d , bool c ) { if ( a > b && c || d ) { a = b; } return a ; }

While this may not look like a big improvement, it will change when done often enough. Do it once and it’s a simple improvement. Do it hundreds of times and it makes a big change. That is not an exaggeration. Those who comment out code will not do it once or twice, but every time and everywhere. Change the direction before your application is a total mess.

The Fear of Losing Code

If you keep code around because you fear losing it, let me tell you the solution to that problem: USE SOURCE CONTROL!

Source control (like Git, Mercurial or Subversion) is there to keep your code save. Learn the system you use to an extend that you know what operations are save and which are not. As soon as you master this level you will not lose code and can get rid of all the clutter. Please do it!

Same Rules for Outdated Comments

Code comments must follow the same rules. There is not much more annoying and misleading than outdated comments. The code changes, but the comments stay behind and misguide you from there on.

/// <summary> /// Field to store postal codes like SW1A 2AX /// </summary> public int Postcode { get; set; } 1 2 3 4 /// <summary> /// Field to store postal codes like SW1A 2AX /// </summary> public int Postcode { get ; set ; }

If you just read the comment (because Visual Studio or Eclipse are so kind to show you the documentation of this property), then you expect this property can store a postal code of an address in England. That may have been true, but the change to integer as the type of this property made that impossible. Yes, the compiler will mark it as an error. But then you have to open the class to figure out why you can’t assign the value SW1A 2AX.

How many times do you need to repeat this experience until you no longer trust the comments?

Conclusion

Don’t comment code out, delete it. Really!

Share this: Email

Print

Twitter

Reddit

Tumblr

Pocket



Like this: Like Loading...