汇编程序员之代码风格指南

本文档为汇编程序员提供了一套详细的代码风格指南,旨在提高程序的可读性。内容覆盖了程序组织、模块设计、语句布局、注释规范及命名原则等方面。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Style Guidelines for Assembly Language Programmers
汇编程序员之代码风格指南


作者:Randall Hyde
  http://webster.cs.ucr.edu/  
译者:jhkdiy
        http://jhkdiy.icpcn.com     or  http://www.20cn.net    
e-mail:jhkdiy_gzb@21cn.net
译期:开始于06年7月4号。结束于8月31日
原文总页数:42页。译文总页数:60页。
   

    大家知道这位作者吗?不知道?晕••••。那看过《The Art of Assembly Language》一书吗?该书的作者就是Randall Hyde。
这本书在国外有很高的评价,以至于国内也有了翻译的版本:《汇编语言编程艺术》。由陈曙晖翻译,我买了但还没看^_^!。这份代码风格指南是我在作者主页里找到的,有空就去浏缆一下吧,或许有意外收获哦!
    在这漫长的翻译旅途中,自己也是一边翻译一边学习该文档的。翻译完后觉得要写出一个易读的程序其实并不容易,但也不是很难,只要自己坚持遵循该文档的话就可以尽能地做到程序易读了。自己学习汇编语言也有一段时间了,却很少在网上的论坛见到过非常易读的汇编程序,绝大一部分是没有任何注释、带有一大堆a、b、d等变量名的难读程序,有一次看到有人特意将整个C语言源代码改成像文字画一样我就跟他吵了起来。无论是汇编也好、C语言或其它语言也好,很多编程的朋友都不把代码的易读性放在眼里,有的甚至从来不考虑,只要代码能执行起来,程序运行起来就算完事了。更有的程序员为编写难读的代码而自我臭美。而大学里教授编程语言的时候,很少有老师对程序的易读性做过教导或建议,以至于学生们从一开始便没有编写易读代码的意识,这在一定程度上增加了编写难读程序的人员。代码是拿来读的,为了能更快更容易地阅读代码,我们必定要遵循一定的规则。
    我真心希望越来越多的朋友能写出可读性好的代码,就算将代码发表到全世界,只要学过该语言的人都能看懂中国人编写的程序,因为它深具可读性,读代码像读诗篇一样流畅而自然。希望这一天早日到来!
                                              jhkdiy
                                                  2006-8-31


《汇编程序员之代码风格指南》

目录:

1.0简介

          1.1 ADDHEX.ASM

          1.2 Graphics Example

          1.3 S.COM 例子

          1.4本文面向的读者

          1.5可读性标准

          1.6怎样做到可读性

          1.7这份文档的组织

          1.8指导、 规则、强制性规则、和例外

          1.9 涉及的语言

2.0程序组织

              2.1库函数

              2.2公共目标模块

              2.3局部模块

              2.4程序的make文件

3.0 模块组织

              3.1模块属性

              3.1.1模块内聚性

              3.1.2模块耦合性

              3.1.3模块的物理组织

              3.1.4模块接口

4.0程序单元组织

              4.1例程内聚性

                            4.1.1例程耦合性

                            4.1.2例程大小

              4.2主过程和数据的安排

5.0语句组织

6.0注释

              6.1什么是一个坏注释?

              6.2什么是一个好注释?

              6.3行终止注释VS独立注释

              6.4未完成的代码

              6.5代码交叉参考到其它文档

7.0名称、指令、操作数和操作                   

        7.1名称

                            7.1.1命名约定

                            7.1.2字母大小写考虑

                            7.1.3缩略语

                            7.1.4标志符内的成分位置

                            7.1.5要避免的名称

              7.2指令、伪指令和伪操作码

                            7.2.1选择最好的指令序列

                            7.2.2控制结构

                            7.2.3同意义的指令



8.0数据类型     

              8.1用TYPEDEF定义新的数据类型

              8.2创建数组类型

              8.3在汇编语言里声明结构体

              8.4数据类型的UCR标准库




因该网站使用了防止盗链技术,请下载文件的朋友使用下载工具进行下载,切勿使用右键另存为!

 
高清晰PDF文件下载
代 码 风 格(1) 随着程序功能的增加和版本的提高,程序越来越复杂,源文件也越来越多,风格规范的源程序会对软件的升级、修改和维护带来极大的方便,要想开发一个成熟的软件产品,必须在编写源程序的时候就有条不紊,细致严谨。 在编程中,在程序排版、注释、命名和可读性等问题上都有一定的规范,虽然编写可读性良好的代码并不是必然的要求(世界上还有难懂代码比赛,看谁的代码最不好读懂!),但好的代码风格实际上是为自己将来维护和使用这些代码节省时间。本节就是对汇编语言代码风格的建议。 变量和函数的命名 1. 匈牙利表示法 匈牙利表示法主要用在变量和子程序的命名,这是现在大部分程序都在使用的命名约定。“匈牙利表示法”这个奇怪的名字是为了纪念匈牙利籍的Microsoft程序Charles Simonyi,他首先使用了这种命名方法。 匈牙利表示法用连在一起的几个部分来命名一个变量,格式是类型前缀加上变量说明,类型用小写字母表示,如用h表示句柄,用dw表示double word,用sz表示以0结尾的字符串等,说明则用首字母大写的几个英文单词组成,如TimeCounter,NextPoint等,可以令人一眼看出变量的含义来,在汇编语言中常用的类型前缀有: b 表示byte w 表示word dw 表示dword h 表示句柄 lp 表示指针 sz 表示以0结尾的字符串 lpsz 表示指向0结尾的字符串的指针 f 表示浮点数 st 表示一个数据结构 这样一来,变量的意思就很好理解: hWinMain 主窗口的句柄 dwTimeCount 时间计数器,以双字定义 szWelcome 欢迎信息字符串,以0结尾 lpBuffer 指向缓冲区的指针 stWndClass WNDCLASS结构 … 很明显,这些变量名比count1,abc,commandlinebuffer和FILEFLAG之类的命名要易于理解。由于匈牙利表示法既描述了变量的类型,又描述了变量的作用,所以能帮助程序及早发现变量的使用错误,如把一个数值当指针来使用引发的内存页错误等。 对于函数名,由于不会返回多种类型的数值,所以命名时一般不再用类型开头,但名称还是用表示用途的单词组成,每个单词的首字母大写。Windows API是这种命名方式的绝好例子,当人们看到ShowWindow,GetWindowText,DeleteFile和GetCommandLine之类的API函数名称时,恐怕不用查手册,就能知道它们是做什么用的。比起int 21h/09h和int 13h/02h之类的中断调用,好处是不必多讲的。 2. 对匈牙利表示法的补充 使用匈牙利表示法已经基本上解决了命名的可读性问题,但相对于其他高级语言汇编语言有语法上的特殊性,考虑下面这些汇编语言特有的问题: ● 对局部变量的地址引用要用lea指令或用addr伪操作,全局变量要用offset;对局部变量的使用要特别注意初始化问题。如何在定义中区分全局变量、局部变量和参数? ● 汇编的源代码占用的行数比较多,代码行数很容易膨胀,程序规模大了如何分清一个函数是系统的API还是本程序内部的子程序? 实际上上面的这些问题都可以归纳为区分作用域的问题。为了分清变量的作用域,命名中对全局变量、局部变量和参数应该有所区别,所以我们需要对匈牙利表示法做一些补充,以适应Win32汇编的特殊情况,下面的补充方法是笔者提出的,读者可以参考使用: ● 全局变量的定义使用标准的匈牙利表示法,在参数的前面加下划线,在局部变量的前面加@符号,这样引用的时候就能随时注意到变量的作用域。 ● 在内部子程序的名称前面加下划线,以便和系统API区别。 如下面是一个求复数模的子程序,子程序名前面加下划线表示这是本程序内部模块,两个参数——复数的实部和虚部用_dwX和_dwY表示,中间用到的局部变量@dwResult则用@号开头: _Calc proc _dwX,_dwY local @dwResult finit fild _dwX fld st(0) fmul ;i * i fild _dwY fld st(0) fmul ;j * j fadd ;i * i + j * j fsqrt ;sqrt(i * i + j * j) fistp @dwResult ;put result mov eax,@dwResult ret _Calc endp 本书中所有的示范源代码采用的都是这样的命名约定。 代码的书写格式 1. 排版方式 程序的排版风格应该遵循以下规则。 首先是大小写的问题,汇编程序中对于指令和寄存器的书写是不分大小写的,但小写代码比大写代码便于阅读,所以程序中的指令和寄存器等要采用小写字母,而用equ伪操作符定义的常量则使用大写,变量和标号使用匈牙利表示法,大小写混合。 其次是使用Tab的问题。汇编源程序中Tab的宽度一般设置为8个字符。在语法上,指令和操作数之间至少有一个空格就可以了,但指令的助记符长度是不等长的,用Tab隔开指令和操作数可以使格式对齐,便于阅读。如: xor eax,eax fistp dwNumber xchg eax,ebx 上述代码的写法就不如下面的写法整齐: xor eax,eax fistp dwNumber xchg eax, ebx 还有就是缩进格式的问题。程序中的各部分采用不同的缩进,一般变量和标号的定义不缩进,指令用两个Tab缩进,遇到分支或循环伪指令再缩进一格,如: .data dwFlag dd ? .code start: mov eax,dwFlag .if dwFlag == 1 call _Function1 .else call _Function2 .endif … 合适的缩进格式可以明显地表现出程序的流程结构,也很容易发现嵌套错误,当缩进过多的时候,可以意识到嵌套过深,该改进程序结构了。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值