Wednesday, June 13, 2012

What is clean code, good code? (Coding skills)

Before starting lets check out why do we need clean code or in fact what is bad code which in turn necessitates clean code.

Bad Code: If you're a programmer then I'm sure you must have seen a piece of code in your application with a huge mess and gradually more and more features are added to that same piece and eventually code got worse and worse until code simply gets unmanageable.  We always try to find our way, hoping for some hint, some clue. of what is going on just to let things work as required but all we see is more and more senseless code. This is what known as bad code. We all feel the relief of seeing our messy program work and deciding that a working mess is better than nothing. At that moment we generally think we will come back to this piece and clean it up but according to LeBlanc's law :Later equals never. :)

Ironically we ourselves are the father of this bad code and we generally try to bemoan this thing to excuse like short deadline, managers, marketers, requirement changes etc. But do consider this:
The managers and marketers look to developers for the information they need to make promises and commitments. The users look to developers to validate the way the requirements will fit into the system. The project managers look to developers to help work out the schedule. The developers are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures; especially if those failures have to do with bad code!! Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's developer's job to defend the code with equal passion. Thus it is unprofessional for programmers to bend to the will of managers who don't understand the risks of making messes.
Clean Code:
Bjarne Stroustrup - "I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimization. Clean code does one thing well."

Beck's rules of simple code:
1. Runs all the tests.
2. Contains no duplication.
3. Expresses all the design ideas that are in the system.
4. Minimizes the number of entities such as classes, methods, functions.

"You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem."

The Boy Scout Rule: It is not enough to write the code well. The code has to be kept clean over time. We've all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation. There is very simple rule:
Leave the campground cleaner than you found it.
If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup does not have to be something big. Change one variable name for the better, break up on one function that's a little too large or doing more than one thing, clean up one composite if statement. This practice will be very fruitful for the project over the time and eventually your application would be in very much stable instead of all pieces of crap every where.

In upcoming posts I'll brief about how you can make your code clean i.e. good coding practices. 


  1. Its a nice read.
    The boy scout rule is awesome! Brings out the problem and the solution to the code degradation problem at once; using the simplest words one could use.