原 文:Style Guidelines for Assembly Language Programmer
原作者:Randall Hyde
译作者:jhkdiy
整 理:jhkdiy
E-mail: jhkdiy_gzb@21cn.net
主 页:http://jhkdiy.icpcn.com 论坛:http://www.20cn.net

自从《汇编程序员之代码风格指南》译作发布以来,收到很多朋友的回信感谢,在此谢谢大家。因为有些朋友说看61页的完整译作不错,但平时不会重复去读,如果可以将每一章的规则整理为一个规则列表就可以当格言和每日提示来看了。我也觉得此想法不错,所以随应大家的建议整理了这份规则总结,规则仍然按章节划分。
在这份总结里只告诉你一条条你应该遵循的规则,但并没有告诉你为什么要遵循该规则,想要全面了解一定要阅读完整的译作或原文,这样才会对规则的来龙去脉有所领悟和理解。相信大家阅读后并遵循这份规则的话可以和国外的一些汇编爱好者有更接近的交流,同时也可以让国外的朋友知道中国人编写的代码也是深具可读性的,而不是一块字符天书。
在此再次感谢原作者,并感谢一直支持我的各界朋友们,祝大家编程愉快!
2006-12-21

pdf文件下载(请使用下载工具下载,不要右键另存为):
http://jhkdiy.go3.icpcn.com/file/download/AsmStyleAllGuide.pdf

第一章摘录:
1.5可读性标准
    有人会问“如何使得一个程序比其它程序更易读?”,换句话说,我们应该如何来衡量一个程序的“可读性”?常规的度量,“我看到一个写得很好的程序”并不是适当的;对许多人来说,这也可以转换为“如果你的程序看起来跟我的好程序很像,那么它们就是易读的,或者它们没有比我的更好”。很明显,这种琐碎的评价标准会因人而异。
    为了开发一个测量汇编语言程序可读性的标准,我们第一个要问的就是“为什么可读性如此重要?”这个问题有一个简单(虽然有点轻率)的答案:可读性很重要是因为程序是拿来读的(而且,一行代码被典型地阅读10次比写一行代码更常见)。进一步来说,考虑到许多程序都需要被其他程序员阅读和维护的事实(Steve McConnell 声称在一个真实的程序世界里程序员需要10次以上的代码维护工作,直到它们被重写;而且,他们算出在他们的工作中有60%的工作是花费在代码简单性上的)。你的程序更易读,其他人就可以用更少的时间来领会你的程序在做什么。也就是说,他们可以集中在增加新功能或纠正代码缺点上。
    为了这份文档的目的,我们定义一个“易读”程序有下列特性:
    •一个“易读”程序是一个能让有能力的程序员(一个熟悉解决程序问题的人)在没有看程序之前就能理解,而且能在最短的时间内就能完全理解整个程序。

那是个高要求!这个定义并不是说非常难达到,而一些不平凡的程序也确实达到了这个要求。该定义提出一个适当的程序员(也就是经常尝试解决程序问题的人)用他们常规的阅读方法阅读(只是一次)就能理解一个程序,并能完全理解该程序。任何小于该要求的都不是一个“易读”的程序。
    当然,在现实中,当很少程序能达到这个目标后该定义就不能用了。部分问题是因为程序倾向于相当长和需要一些人有在同一时间里在他们脑中管理大量细节的能力。而且,也不晓得一个写的好的程序会是怎样的,“一个有能力的程序员”也没有提出程序员的IQ需要高到阅读一个语句就能完全明白它的意思而无需想太多。因此,我们必须定义可读性,这并不是一个真假事实,而是一个衡量范围。尽管存在真正难读的程序,也有许多“易读”程序比其它程序难读的情况。因此,或许下面的定义更现实一点:
    •一个由一个或多个模块组成的易读程序。符合要求的程序能做到随便选取程序中的一个模块,对程序中的每条语句平均花费不到1分钟就能理解80%。

    80%的理解程度意味着程序员能修正程序的错误和增加程序的功能而不会因为对手头上代码的误解而犯错误。