Better looking code has fewer bugs in it

The most important thing for me about code is its looks. I might sound crazy, but bad looking code makes me cringe. Whitespace is the single biggest factor defining the looks for the code. Variable naming is also important, but as long as it is consistent, it doesn’t matter nearly as much as whitespace usage.

There is actually a reason why I rave about the importance of looks in code. Better looking code has fewer bugs. Let me say it again with all caps: BETTER LOOKING CODE HAS FEWER BUGS.

There are many reasons for it and I will try to prove it to the best of my abilities.

Whitespace should be used to separate things. By writing

    variable_x+variable_y-variable_z*variable_y

it takes a while to see what is actually happening in the code. If the whole thing is written without any whitespace, it is hard to know where a variable begins or ends. By writing

    variable_x + variable_y - variable_z * variable_y

it is immediately clear what is happening. It takes less time for the brain to visually gather all the needed information from the line above. All of this was achieved by pressing the biggest key on the keyboard six times. The space key is so huge that I don’t understand, why many programmers have hard time finding it.

Because the second example is more clear, the bugs in it are more obvious. Let’s say that instead of using a ‘-’, there should be a ‘+’. This might go unnoticed in the first example, but the operators are more visible in the second one, and the problem can be caught more easily.

Whitespace doesn’t only limit to space characters; newlines are also really important. Code should be structured by modules, functions and blocks of code inside the function. If the function is one big block of code without any newlines, it is impossible to quickly get a clear picture of what is happening in the function. The return key is also quite big, but still many programmers are able to avoid touching it for long periods of time. Some programmers claim that if code has too many empty lines, enough information cannot fit one screen. I have one advice for you: Buy a bigger monitor. If you still want more lines, turn it 90 degrees. Now you have so many lines visible that even the most verbose Java code with plenty of empty lines manages to provide a lot information in your Eclipse.

Example 1:

    lines_of_code;
    another_line_of_longer_coder=xyz;
    for(i=0;i<12;i++)
    {
        print("ILIKEDENSECODEBECAUSEIAMARETARD")
        another_print("NOTHING");
    }
    long_calculation=1262+3222-3423^32424>>1233?1:0;
    //comment hidden here so you won't see it
    another_useless_line_of_code_that_does_absolutely_nothing();
    move_along_nothing_to_see_here();

Example 2:

    lines_of_code;
    another_line_of_longer_coder = xyz;

    for (i = 0; i < 12; i++)
    {
        print("I DON'T LIKE DENSE CODE BECAUSE I AM NOT A RETARD")
        another_print("NOTHING");
    }

    long_calculation = 1262 + 3222 - 3423 ^ 32424 >> 1233 ? 1 : 0;

    // comment not hidden anymore
    another_useless_line_of_code_that_does_absolutely_nothing();
    move_along_nothing_to_see_here();

Who can honestly say that the first example is better than the second one in any aspect?

Not only does elegant code make the bugs more visible when looking at the code, but bugs are also more visible when looking somewhere else. There have been many situations where I have found bugs in code, when doing something completely else. Beautiful code leaves an imprint in my mind, and sometimes I know exactly where the bug is. I cannot do that with ugly code. I cannot bend my mind around ugly code and walk through it with my eyes closed.

Too long lines and too long functions also prevent me from seeing the code in my head. If the function is short enough, you know everything that is happening in the function and in what order, but if the function is too long, you get lost and don’t know what is happening in the function without looking at it. Long lines, which I already complained in another blog, also hide bugs and prevent me from visualizing the code in my head.

There is never a good reason to write bad looking code or deviate from coding standards. It takes only about 2% more time to write proper code, but most the time should already be spent on thinking. If the 2% is too big for you, maybe you should switch your editor to a proper one or get a new profession, because I don’t want to work with people, who cannot follow simple agreements.

  • Share/Bookmark

5 Comments

  1. Exactly, code is primarily written for humans to read. Less lines does not necessarily mean less code. As the epic visual C++ tip of the day says: “Always code as if the person who will maintain your code is a maniac serial killer that knows where you live.”

    But I can think of at least one good reason to deviate from a coding standard – when the coding standard is retarded :)

  2. tuomas says:

    I agree. I wish everybody had gone to SSH school of coding. World would be so much better place :)

  3. A few thoughts:

    - Always handle errors at once and return/exit at once when one has occurred. Don’t let the code execute past an error condition. It’s the worst thing when you have to worry about all the possible side-effects that can happen if this rule isn’t rigorously followed. Just flagging an error isn’t enough.

    - Always hide the ugly details. On the top level the code should read almost like an index of a book so that you can quickly get an overall picture of what it does.

    - Naming convention is more important than how you use white spaces. I can always re-format your code, but I don’t want to wonder if you meant bacteria or a bank account when you wrote `int bact’ into your code. Reverse engineering what you meant w/”XB” when the production system is down isn’t too much fun, either.

    - Please comment _why_ your code does the thing it does. I can see _what_ it does from the code.

    - Reduce logic, like it was math. Don’t handle a gazillion cases in one if-statement, unless the logic simply cannot be reduced. Could you simplify it by reversing the if to not-form?

    - Please emphasize what you mean with using x + (3*y) + 4 instead of letting me wonder did you do x + 3 * y + 4 on purpose or by mistake. Even x + 3*y + 4 is better.

    - Please don’t get clever w/boolean logic. Just make it easy to read. Generally, follow the “don’t make me think” – principle. I can assure you that the task at hand is oft quite complex enough w/o added subtleties.

    …There are so many things, but I’ll give it a break now. :-)

  4. I can agree that using parenthesis makes it more clear, but I would never leave the whitespace out. So I would write x + (3 * y) + 4.

Trackbacks / Pingbacks

  1. uberVU - social comments

Leave a Reply