今天测算了一下老胡做的LEGO赤道仪的旋转速度。在18分钟内，安装在其上的激光笔在4.5米之外、1.1米高的位置投射的光点移动了357毫米，这就是说，每秒，它旋转的角度是arcsin(0.357/4.6325) / 18 / 60 = 14.73角秒，这样，每个恒星日（23小时56分钟4秒），它的旋转角度是352.62度，和360度完美圆周相差2%。考虑到激光笔的投射距离是用地毯拼块和A4纸测量出来的，2%的误差完全在我的期望范围内。

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.
猛击阅读全文

有偷懒的态度不算稀奇。
有偷懒的能力，才是人中龙凤。

老胡拿LEGO零件做了一个赤道仪。只要在图片上方的齿轮大孔里装一个寻星镜，并对准北极星，那么，左上角的螺钉上安装的照相机相对星空就是静止的，可以避免长时间曝光的星体拉丝现象。赤道仪有马达驱动，齿轮大孔的旋转速度是每天360°。整个部件仅仅重五百克。

盛赞老胡！

Equatorial Mount built with LEGO pieces

埃蒙小镇真是纷乱尘世里的一方净土。

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.