Source code readability is important. Even nobody else will read your source code in the future, you will read it one day. Dirty code provides good shield for bugs for they become harder to find. Dirty code may also mislead other programmers to think they find a bug, and by “fixing” it, they create a real bug.

Indention

One good reason I like Python is, no matter the programmer is amateur or professional, at the first glance, the source code is so clean. If the source code is not properly indented, then it may not run at all. Well-indented source code helps the reading speed, and makes the bugs easy to reveal.

There are many code beautifiers that standardize the code style. For example, in UNIX there is a command called “cb” (C Beautifier), and in Visual Studio, there are shortcuts standardizing the code format as well. When I programmed in C, I always ran the “cb” command and compared the output with my source code, and made sure no differences were found between the two. Call me obsession, but once I got used to it, it became very natural to write well formatted code at typing.

Explicitness

Being explicit means, for example, if part of the code is supposed to do nothing, then, instead of writing nothing, do put some code or comments to speak out: “I am here to tell you, nothing should be done. I did not forget to consider this case.”

Here is an alarm clock program. It used to work before but is not working now. Instead of triggering the alarm by the desired time, it does the inverse logic – keep ringing the alarm until the time is reached. The investigation shows that the latest version is like this:

for (time() < desiredTime)
    puts(“wake up”);

Then no surprise why it keeps sending the alarm. Why the code is like this? One week ago Susan read the code and discovered that the code was like:

for (time() < desiredTime);
puts(“wake up”);

and she thought that the “;” at the end of the “for” statement was a typo, so she removed the “;” wrongly, and this “fix” ultimately reserved the logic.

To avoid this misunderstanding, Mike, the author of the previous version, should have written his code as below, so if Susan saw this code, she would have been thought twice, or picked up her phone to quickly confirm with Mike, before applying the “typo correction”.

for (time() < desiredTime)
    ;
puts(“wake up!”);

A even more explicit code is like this. The “NULL” statement does not generate any extra code, but it explicitly tells the audience “I mean to do nothing here.”

for (time() < desiredTime)
    NULL;
puts(“wake up!”);

Other examples: The NULL statement in the “else” block makes explicit that no actions should be taken if neither A nor B is met. The “fall through” comment in the “switch” block makes explicit that the “break” statement is not forgotten here, but the programmer intends to execute do_this() and do_that() when a equals to 0.
猛击阅读全文

A myth says, and lots of people believe, that every program has bugs.

This is only a myth, however. Consider this program:

void     main(void)
{
}

This program has no bugs, because it does not do anything. This program has lots of unsupported features, however. It does not do whatever we can think of, or in other words, the entire world is its complement.

You may say this is a quibble, and tweak the statement a little bit and say: Every acting program has bugs.

Then please consider this famous program, which does nothing but printing “hello, world” followed by a line-feed:

#include <stdio.h>

void     main(void)
{
   puts(“hello, world”);
}

We acknowledge that this program has lots of unsupported features as well. It cannot print “good morning, world”, “goodbye, world”, etc. However, again, it has no bugs.

A program may have unsupported features, but can be bug-free. In my 19-year programming life, no post-release bugs were discovered from my codes. I worked for a company that manufactured semiconductor measurement instruments. I wrote a program that made the company’s program looked like sequential execution, but actually run in parallel way. The patent-owning program had over 2000 lines, and since the day its first version was written (2003), the company’s QA team did not find any bug from it. Two years after I left the company, I talked with my ex-colleague by chance. He told me that the guy, who was assigned the QA to audit my code, did not find a single bug. But since the QA believed the myth “Every program has bugs” so blindly, he preservered with it for two years, and ended up with nothing.

When I was young and arrogant, I drafted a “bug-free guarantee” and attach it to every piece of my source code, and said:

If anyone finds the first bug in my code, I would pay him/her 1 dollar, then for the second bug he/she finds, I would pay 2 dollars. 4 dollars for the third, 8 dollars for the fourth, and the number increases exponentially.

Nobody ever got a buck from me.

In theory, in reality, bug-free development is possible. I am planning to share ideas about bug-free programming in some of my future blogs. Such blogs will use “bug-free” tag.