友诚机麻
- 2012年05月11日
这张立体转山地图是在Google Earth的基础上绘制的,标记了沿途各点的时间。黄色/橙色/红色的时间点表明,要到达这里需要耗费相当的体力,颜色越红,越是吃力。转山路线为绿色,表明此处是下坡。橙色或红色表明是上坡,颜色越红,越是陡峭。以上颜色假设,转山者是顺时针转绕仙乃日圣山的。三怙主雪山的经纬度是(28.38, 100.37)。
清晨6:20从龙同坝出发,此时天色已亮,7:15到达冲古寺。在大玛尼堆前供罢护法,向洛绒牛场进发。
8:35,经过神水门后,道路两侧的山崖缓缓打开,雪色晶莹的央迈勇,仿佛是一瞬间出现在天边。七年前,我第一次来的时候,他也是这样突然闯入人们的眼帘,刹那之间,夺走你所有准备好的赞美之辞,只留下你脸上的两行热泪。
9:20走到了洛绒牛场,早晨防寒的羽绒服已经被汗湿透,外罩冲锋衣的内侧也结满了汗水。在栈道上借用炽烈的阳光晒晒衣服,顺便吃吃早点。
9:40接着出发,经过牛场的木屋时,拐进一户人家讨水喝,顺便把水壶续满。临走时想给女主人一些钱,被她笑着拒了,说水来得好容易的,要什么钱呢?
猛击阅读全文
今天测算了一下老胡做的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.
猛击阅读全文
It is important to understand the differences between the physical world and the computer world, and keep the differences in mind.
A computer, most times, is only simulating the actual world. As a result, if the simulation is not well designed, then a program may get incorrect, inaccurate, and/or inconsistent result. A function once worked one month ago may no longer work today, or its behavior varies from one computer to another. If I said these in front of a programmer, he/she would probably agree. This does not mean he/she would keep this in mind, though. I have seen many cases when the program inaccurately simulated the world, its master’s first instinctive reaction was to check somewhere else, but not their own code.
When writing programs, the developer have to keep alert of these differences, and when introducing his/her code to others, he/she can easily tell which items are representing the physical world, and which can stand true only on a computer.
猛击阅读全文