Messy code, impressionism and music

Computer programming is often compared to two forms — art and engineering (trade, science). That duality is very convenient for the developers — we have a universal excuse for almost any situation, just pick the right side.

Usually the excuses fall in the “This is an Art” category. Hard to quantify, hard to get right (on first several passes), hard to explain, hard to… whatever.

Or, in case of the client expressing their problem in vague terms, we like to appeal to programming being “an engineering”, forcing the client to express their dream in an unappealingly precise fashion. Something that most people can't even do, including programmers (you should see some explanations we sometimes produce).

And sometimes — sometimes, — it is true. Software development does require creativity, inspiration, passion; it also requires precision, patience, cold-headedness.

There is at least one area, though, that I believe being an art form is a silly and damaging excuse. That's code clarity.

Painter workshop

Imagine: a developer is working on a new concept, using a new technology. It is all hot, buzz-wordy and exciting. So far so good.

Then you take a look at their code, and — oh my keyword, — is it a mess. Broad brush strokes chaotically layered over, shapes of previous failed attempts sticking out here and there, fresh paint dripping off the canvas' edge. Look at the artist himself — stepping away from his masterpiece, covered in dye splatters head to toe, breathing heavily, blushing, happy.

Ah, beautiful. I can even smell it!
Photo by Kelly Rowland
“It works!”

So it does. Yet source code is not a painting, and you're not an impressionist. Problem is, one day someone may need to slightly change this logic. Someone may have to fix a bug or two (and, after a painterly approach to code writing, there are usually more than one or two bugs left). Finally, someone may need to understand how it works and what it does.

That somebody could even be the original developer, yet ask him half a year later, and he won't be able to read it. Hopefully, he'll still remember that he was the one writing it, so he won't swear too much. Though swear he will.

Keep it readable

The short version: keep your code nice, neat and clean.

A longer version: employ every tool at your disposal to make it nicer, neater and cleaner. Every little bit helps. That's where comments, thoughtful file structure, meaningful object names, formatting consistency, all come in handy.

These tools feel like an obstacle when we are in the heat of a creative moment, but, if used wisely, we'll thank ourselves later: “Thank you, dear Me From The Past, for being so thoughtful of me. Sincerely mine, Me In The Present.”

Music to my eyes


Beautiful even without listening.
Photo by Michael Janssen

A word about formatting — it sounds very mechanical and artificial, but it is important. Bracket placement in functions and conditions, space usage in complex expressions, indentation rules — it all matters, because it creates a visual rhythm. It makes the code organized on both conscious and subconscious level. It makes parts of logic recognizable even on quick scroll-throughs.

It makes code reading — and our life, — easier.

In music (trying to study it now, I mentioned it earlier) there are certain intervals between sound pitches, they are called harmonic simply because they sound good to our ears. Reuse of those intervals creates recognizable phrases, and a collection and repetition of several phrases creates a melody.

You've got to be kidding me.

My fellow developer, if you insist on seeing your work as a form of art, don't always liken yourself to a messy painter. For your own good and for the sanity of those to work after you, follow in the steps of great composers, put enchanting music in your source files.

Or compose a “Death Waltz”, if you like. Just not in any of my projects!

Comments

  1. In my opinion, your explanations are useless for those who do not already agree with you, or who never thought about those things or experienced them themselves.

    But for those who agree with you it is a nice post which allows us to thoughtfully nod our heads in agreement while we read it. Thank you. :)

    As for constructive response, I think that the most efficient way to teach those things is to throw a developer into the sea and let him try to swim without any explanations, watching him and helping him without any explanation or word only in cases when he is in endless loop or just bangs his head against a wall. That is, let him write much code, then let him add new features to it, then let him rewrite parts of it as a requirement. And repeat this in cycle until he starts to write code the way you described in your post. By the way, giving a lot of stress (see one of your previous posts) during the whole process will help most lazy ones. ;)

    ReplyDelete
    Replies
    1. > let him try to swim without any explanations

      Perhaps that's why I carefully tailored my explanations to be perfectly useless! ;)

      Still, may be someone somewhere will listen to us grumpy old men and will finally understand, that the reason for his pain is in himself — and, magically, will improve.

      Though learning on one's mistakes remains the most efficient learning path, sadly.

      PS And I like the music comparison, regardless of how useful it is. Art for the sake of art FTW!

      Delete
    2. >And I like the music comparison

      Yup, I'll call badly formatted code a "death waltz" from now on. :)

      Delete

Post a Comment

Popular Posts