The Art of Clean Code

Now lets say you believe that messy code is a significant impediment.and also you accept that only way to go faster is to keep your code clean.Then here comes the question you need to ask your self

“How do I write clean code.?” Its no good trying to write clean code if you do not know what it means for code to be clean!

Writing clean code is a lot like painting a picture. Most of us know when a picture is bad by looking at it self. this doesn’t make us to be a good painter or know how to paint. So too being able to recognize clean code from dirty code doesn’t mean that we know how to write a clean code!

Monalisa Good Painting     MANA LISA
Andrea Schmidt, Vancouver, Canada
12"x16", oil on canvas
Donated by the artist, January, 2002
MOBA #370

A cross-gender interpretation of the daVinci classic. Mana Lisa’s nose strikes nimbly, offsetting the dialogue between the foreground and profoundly varnished background.
Further, by deciphering this work’s title, perhaps we can contribute to the growing body of Leonardo's anagrammatic discourse:
MAN ALIAS
I AM NASAL
A SAIL MAN
AS ANIMAL
AM A SNAIL
MAIL NASA

From—Museum of Bad Art: Masterworks by Michael Frank and Louise Reilly Sacco

 

Writing clean code requires the disciplined use of extremely great number of little techniques applied through painstakingly “acquired” sense of cleanliness.The “code-sense” is the key.

Some of us are luckily born with it. Some of us have to fight to acquire it.Not only it lets us to see whether a code is good or bad, but also shows us the strategy for applying the

discipline to transform bad code in to clean code.

 

A Programmer with out “code-sense”  can look at a messy code and can recognize the mess but will have no idea what to do about it.But a Programmer with Code-Sense will look at a messy module and see options and variations and can choose the best variation to solve that mess

 

“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines
of control.”-Grady Booch,

Advertisements

Attitude

 

Have you ever worked on a code that should have taken hours to compete and you took days to complete it. Have you seen what should have been a one-line change but that change impacts many modules and hundred of lines have to be changed to achieve that.

 

Why do you think that happens ? is this because of bad code? I am sure at first you might of taken care of writing good code and what happened to that good code? what contributed you writing bad code

Many of us might complain its because of change in requirements, or tight schedules to do the things right. But I believe its because of us the developers. developers should take blame for this rotten code, NOT the managers or customers.

 

its our responsibility to tell our managers that “hey this code is shit, we need to refactor it first before we do any changes to it”, when your manager says finish this at any cost.and believe me most of the time your manager would listen to you, even they are obsessing about the schedule.

 

to drive this point, consider what if you are a doctor and had a patient who demanded that you stop all the silly hand washing in the preparation of surgery because its taking too much of his time . would you listen to him? since he is the boss!. it would have been unprofessional(rather a crime!) if you would have listened to him.

So too its unprofessional for programmers to bend  to the will of Managers who don’t understand the risks of making  a mess.

All the developers with more than few years of experience  know that bad code slows you down,and yet we choose to make messes in order to meet deadline.

 

True Professionals do not make a mess of a code in order to meet a deadline. They know that the mess will slow them down eventually and will miss them to miss the deadline. So they know out of their experience that – the only way to go fast – is to keep the code as clean as possible at all times.

Later equals never

if you have been a programmer for more than 2 or 3 years, have you ever been impeded by bad code written by you or your team.? when i say impediment, what i think about impediment is if you were asked to do a change and it ideally should have taken less time, but practically it is never the case, doing small change requires making lot of other changes.

I think this will happen because of bad code. and ofcourse this bad code was written by us the programmers. but why do you think we write bad code? may be because of

we are trying to go fast or we were in a rush ignoring the principles , perhaps we were ignorant or tired of working on program for so long and may be frustrated because of this or promised to your manager to get it done by this time at any cost! or may be something cool coming up and you were pretty excited to get it started so didn’t concentrate on the current task in your hand.

and most of the time you know the program is in a mess and you have choosen to leave it for another day since you might have relieved by your QA confirmed that the code is working.We all have done it. I had done it saying to ourselfs we will come late and clean this up!

There is a law called LeBlane’s law which says ‘Later equals Never’. Now you know the law and its applicable to us