Golden Rule of Coding

Minimize surprize for the maintainer.

This simple rule sounds too altruistic. Why should the coder care about the maintainer?

The answer is in the law of Karma. As you saw, so will you reap.

If you are not of religious, think selfish. (Even if you are religious, I won’t stop you from thinking selfish.) What if maintenance of the code hits you after you have moved away from the code? Unless you are hoping jobs as if there is no tomorrow, practice of compassionate programming is going to help you first.

No matter how much we despise QA, bugs surface. No matter how much we get angry at the marketing folks, requirements change. Requirement changes and bugs will force you to go through your own creativity. What appeared as job security while coding would come back as curse during maintainance.

Compassion is the key. But how does that key look like? How could you be compassionate to the maintainer when the designer was not compassionate to you?

Reduction of surprise translates in reduction in indentation of the code. It also translates in writing the code as soporific and not as a candidate of “understand me if you can” challenge. While most of us most of the time don’t intend to write hard to understand code, we inadevertantly end up writing it.

Writing less indented code is under your control only in part. Bad design can undo a lot of good effort from bona-fide coder in this area.

However, if we reduce the control structures we use, we force patterns in coding. Once we force patterns, the maintainer has to think less.

Then, what control structures should be our choice? Theoretically just two of them suffice – “if” and “goto”.

Wait a moment! Am I asking you to throw all progress in methodologies in a garbage can? “goto” is the sworn enemy of a good design, isn’t it? And what about all my grudge against “if” in the same blog?

I did not suggest to converge to the theoretical minimal of flow controls. I am a fan of methodologies and suspicious of most “if”s written in the world. Then what in the good computer am I talking about?

Here is the list of my preferences: (I am going to expound on each of them in future postings)

1. “goto” – think of slimmer functions
2. “not” – think positive
3. “else” – minimize surprize
4. “else if” – just in case … – and rswitch
5. “if” – only if …
6. “switch” – did you consult a domain expert?
7. How to not to avoid decisions?
8. “while”, “do-while” and “for” – choose one
9. Why do I love associative arrays? Separation of Rule Base, Data Base and Object hierarchy?
10. Why do I love programming by contract? OOP? AOP?

I think I will stop here and then write a posting on each of the above.


2 comments on “Golden Rule of Coding

  1. partha says:

    IMHO, You should also consider a few more aspect here,

    11. Coding documentation:
    i guess that should be one of the first point.
    A code without little or any documentation is as good as rewriting the code. A code might have a obscure bug which might surface after X years (Y2K). Function purpose, statements, arguments and return value

    12. Libraries :
    While designing one of the greatest emphasis should be in getting libraries done first. Think of a piece of software with n module in which every module have a different ADT (Abstract Data Type) implementation. Its a real pain in the **** during maintenance and bug fixing. ADT are to be there for application programming benefits and not for “individual heroism”. The ADT’s should be generic. say i should have a doubly link list implementation which should suffice all data types in my code. I would stress over here on using existing libraries available with the OS. Why reinvent wheel?

    13. Obfuscation :
    if (((var & VAL1) || (var & VAL2) ) && (var 2 & (flag & FLAG_VAL_2))) {

    What am i trying to do over here ? Is this readable ? tell me how long did it take you to read the code ? I know that the programmers are the most intelligent chromosome available on this planet, but your over sight might be a cause of immense mental masturbation for other. I agree that programmers should not be restricted in their creativity but it should not be abstract art, where i need a painter to decipher it. Your creativity should be in your program design and not coding.

    14: strange obsession with malloc :
    Usage of auto variable in places where necessary. auto variable are meant for the code as they are also needed in bangalore roads.

    14.a : scoping of variables and functions :

    15. A special section on return.

    16. Just to elaborate on your point 10, c programs can be made object oriented (states and func pointers). they look neat, crisp and crunchy. How c programs can be made to be designed following OO Principals. For u guys who thinks that c programs and OOP are like sleeping with the enemy, then yes i’m a moron.

    17. Choice of an algorithm in a program.

  2. bhushit says:

    Will you please elaborate on your points a little bit more?

    I will be happy to expound on #16 as I have repetitively refactored non-OO (but non-C) code to OO code.

    However, my objective was never OOP but better P. So I just followed all the steps I mention from 0 to 10. I inevitably ended up in OOP.

    With regards,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s