Code Clean...

On my previous .net project I was working in an onshore-offshore model, with the solution architect being from the client. The project was about a client's product of which 3 versions were already released & for version 3.1 the client had given us some good chunk of work, which we were supposed to develop at offshore. What we had been communicated was that the architect is a perfectionist and does a very thorough code review, reviewing almost every line of code written. Before the project, he had sent us Coding Standards Document and wanted us to folllow the document as closely as possible. Like almost all the developers who fret at documents, I read the doc and though most of the "best practices" looked good to read, I thought they'd be tougher to implement. The guidelines had things like there shouldn't be any dead procedures, variables in the code, no commented code, no class should be more than 5000 lines of code(or some magic number), no method within a class should be more than 250 lines, two methods declaration should be separated by a blank line, no blank lines within a method etc. etc. The logic of these guidelines being that 80% of the times the code is maintained by some one other than the original developer and since most of the time/money is spent on maintaining an application, it makes sense that the developer writes "readable" code. The two things that I found pretty hard to follow in the guidelines were "No commented Code" and "No dead dead", which I guess is problem with most of the developer's code. These problems persist because once the developer thinks that the code is "stable", he is very sceptical about modifying it, this thing comes from the age old adage: "Never change a working code". Now if due to some change in business requirements once the code is stable, the developer has to change his implementation, he will always comment out the older code, just in case the newer code doesn't work or the business requirements are again reverted back to the older one. The problem is even if the newer code works and the newer code is stable, the older code remains hanging in the application commented. I also used to keep my older code commented in my applications, the logic being the commented code is not compiled so it doesnt hurt in anyway...one more developer's problem, most of the time developer's seem to miss the point that most probably someone else would be looking/enhancing/bug-fixing their code. Dead code can also be attributed to the same factor, developer being too weary about changing a stable code. Now that I have been working on another project, I realize the importance of the above guidelines. One of my responsibility was to enhance an existing piece of functionality and the developers who wrote that piece of code had been long gone in search of greener pastures. Just glancing at the code made me fret, one class had nearly 2000 lines of code, of which about 500 lines were commented out(some had comment date of around 2 years back!!) and around 500 lines were dead code!!! So the class was only around 1000 lines, the first thing that I did was remove the commented out code and dead code, which made the code a lot more readable and pretty easy to build upon. I feel writing "readable" code is one of the most important factor for any project to be successful in the long run and believe me it does not take too much of time once you get in habit of writing good quality code.