Creativity at Code Level Considered Harmful

You must have read the Go4 book for design patterns. If you have not, take a week's vacation and invest it in reading the book. When you become millionaire using those ideas, remember me.

Seasoned designers hold on to their creativity till their problems are resolved through these and other known patterns.

The pattern approach has actually become so successful that proponents of new methodologies like AOP and new approaches like AJAX have come up with patterns to communicate their promise.

Why are patterns so popular? The disadvantages of not following patterns are louder. Even designer is in the state of fuzzy mystery about what she is doing. Using patterns, on other hand, prepare all "non-designers" on what to expect.

Somehow, on coding level, none seem to bother. Worse, the so-called "experienced programmers" are anti-pattern. You must pardon my ignorance about absence of well-known coding patterns. As a result, coders discover a new method of solving a well-known problem – sometimes eight times in a function!

This situation keeps level of creativity in coders and level of excitement of debugging in maintainers very high. Barring these "advantages", it is obnoxious. For example, this is a snapshot from a real-life code. Can you make sense of it as a maintainer?

if ((x == MACRO1) && (foo(a,b) ? !((y || z) && (z & MACRO2)) : TRUE )) {
    /* B L A H */
Try to recollect your experience of maintaining a piece of code that sets defaults or checks arguments. How many ways human creativity has unfolded before you? In turn, how many ways you needed to reverse-engineer that creativity? Interestingly, how much time did it cost?

The only time I believe a genuine code creativity has brought glory is Duff's device.
That is why I love programming by contract, though I never got a chance of working with it. One step further, I prefer modification of prototype declaration in C/C++ that allows explicit assumptions about arguments. Through compiler prologues, these checks should be implemented. For example,

int foo ( int* x != NULL, int y > 0 );

One step further, I also advocate allowing explicit promise of return values. This can be implemented through compiler epilogues. For example,

int foo ( int* x != NULL, int y > 0 ) > 0;

Do I even need to explain the prototype? "foo returns a positive integer and takes a non-NULL integer pointer and a positive integer as arguments".

This may look like hair splitting. However, look from the maintainer's angle – or the library user's angle. How much information is conveyed through simple change in syntax!

A lot of code level creativity that went into verifying arguments was deftly pushed to the compiler. Once the compiler is debugged, all problems regarding unsatisfied arguments are by and large taken care.

In the previous posting I have mentioned about the defaulting pattern. Why should there be a need to use "if-else" pair at all? The "else" clause of such a pair is nothing but default! At length I have described how a maintainer would find such a "default-if" pattern easy.

In the course of this blog, I believe more and more such coding patterns would emerge. Most of you would have noticed such a pattern. Please write them in the comments.



One comment on “Creativity at Code Level Considered Harmful

  1. partha says:

    OOPS !!! i did it again !!! i started reading your blog from the last post, so had put some comment on code creativity later.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s