Coding is considered the most simplest
of the tasks in a software development life cycle. Most people I have seen want
to get the code right the first time they write, a bang for buck for the time
spend. If only it works that wayJ. But the
interesting part is that good code is hard to find. It’s not quite too often
that I hear the words – “We should corner the guy who wrote this and beat the
hell out of him”. So what makes people write bad code? Just a code review that
went horribly wrong or the programmers coding concept which is wrong or a cheat
sheet of best practices in coding which is way too wrong? The blame as it
stands invariably shifts among all the three and comes a full circle back to
the developer.
In my earlier posts I have mentioned
instances where we were able to optimize code to such an extent that, it cut
down cpu and run time of a process that the result send shockwaves through the
developer community in the firm – A process which was running for 1.5 hrs
printing 6 records in the output and consuming a good load of cpu a year began
running in less than a minute and using cpu that would have last another 30
years if it ran every day as compared to its usage for 1 day now.
Well that puts us in a spot. And that
brings to question, what’s a good coding practice? Or is there definite
guidelines that one need to follow? Or better still, how good do you know your
technology?
A few thumb rules go a long way:
·
Know your data
·
Make sure you have a design (either document
it or have it in your mind)
·
Run the design through your team or peers
(however small it maybe)
·
If you are planning to use any jazzy feature
see how good it performs in the system or better still check with someone who
has used it
·
And if possible get a code review with an
expert in technology
