15个编程好习惯.doc

15个编程好习惯编者按：这是国外程序员Al katib总结的一些编程习惯。1. 动手编码之前，你需要对要编码实现的解决方案有一个正式的或粗略的设计。永远不要在没有任何设计的前提下就开始编码，除非所编代码不重要。2. 优秀的代码文档跟编程语言知识一样重要。在代码源文件中，为每个主要的代码段添加注释，解释代码的基本逻辑。最好注明程序的构建和修改日期，以及修改的原因也是非常有必要的。3. 维护程序的各个版本同样重要。当前有些编程工具都自带一个版本管理工具。无论你什么时候改变自己的程序，它们都会将其保存为.bak文件。我的方法是为每个程序维护三个不同的版本。比如说，我有一个名为program.c的文件，这个文件同时也被其他项目组成员使用。我把这个文件复制为program.c.old作为备份文件，并且当我修改时，我会备份另一个名为program.c.wrk的副本文件。当成功完成修改时替换program.c.wrk文件。你还可以给自己的程序版本添加一个日期或一些注释，像program260505.c或programReadFnWrking.c。4. 如果工程包含多个源文件，则创建一个README文件，注明每个源文件、数据文件、临时文件以及日志文件(如果有的话)的作用。你还可以注明编译和运行步骤。5. 有时候，你一定想知道为什么IF语句没有得到预想的结果。可能你使用的是等号，也就是“=”，而不是条件判定符号“=”。一个比较好的办法是用相反的顺序写条件语句。因此，你的条件语句应该如下：if(10=i)因此，如果你错误地写成了单个等于号，在编译的时候也能检查出来并报错。6.使用循环和条件语句时，先把左右括号对应起来，然后再在里面写其他语句。也就是：代码:1 for(int i=0;i10;i+) 2 4 printf(“i=%dn”,i); 3 注：每一行开头的数字表明写循环代码的顺序。7. 避免使用幻数（magic numbers）。例如，不要写代码:circleArea = 3.14 * pow(radius,2);而要使用如下代码：代码:#define PI 3.14 circleArea = PI * pow(radius,2);8. 使用有意义的变量和函数名称。例如，使用radius来代替圆的半径，而不是用r来表示。同样，函数名calculateArea要比其他任何隐晦的缩写要好得多。匆忙之下，我们也许会使用缩写的变量名，但一开始节省时间的话，之后会浪费更多的时间，去猜测缩写变量名代表什么。（编注：）9. 为后面的调试使用打印语句，这是个好习惯。但是，当完成最后代码后，去掉这些语句，有时也是一项危险的任务。添加一个方法，用于输出调试信息。当最终版本生成时，只要把这个方法注释掉就行。因此，只在一个地方做修改就可以了。10. 代码编写完之后，开始优化代码。之前声明的一些变量，现在可能没用了。同样，并不依赖循环的一些声明可以移到循环模块之外去。扎实的编译知识同样会对以后的代码优化有所帮助。11. 对自己的操作系统和硬件要有足够的了解，你可以从资源占用等方面提升程序的性能。12. 编写代码时要合理使用缩进，以使代码清晰可读。13. 把项目文件放到SOURCE、HEADERS、MAKE、EXES等不同的文件夹中。14. 研究别人编写的代码。这可以让你学习到新的编程技术，以及他们解决和你相同的任务时所使用的方法。15. 最后一条（但不是最不重要的一条)，备份源代码文件，这样当硬盘出错或相同的问题发生时，不至于前功尽弃。附加：补充一条，坚持使用一种命名模式。如果你打算用匈牙利命名法，那就坚持并广泛使用，否则将适得其反。参见微软资深工程师 Eric Lippert 的这篇文章阅读代码不简单。编者后话编程的好习惯应不止这15条，也许您不认同上文中的某些观点，请标出相应序号，并说明其不足之处。另外，非常欢迎大家补充分享您的好习惯。附文：微软资深软件工程师：阅读代码真的很难为这篇文章评分窗体顶端窗体底端0 评论发表人：关关发表时间：2011-01-07 11:48 AM编者按：原文作者Eric Lippert是一名资深软件设计工程师，从1996年起一直在微软开发部门任职，协助设计并实现VBScript、JScript、JScript .NET、Windows Script Host、Visual Studio Tools for Office 和 C#。Escalation的工程师JeremyK在他博客中问到：你是怎么教人们快速深入挖掘不熟悉的代码（不是自己所写的）？我学习如何编程的方法很传统 自己动手编码。但我现在很纠结：到底是集中精神阅读源码，还是自己编写。对我而言，似乎唯一有效的方法就是自己写过。不是和Jeremy开玩笑，写代码的确没有读代码难。首先，我同意你的看法，几乎很少有人能读代码但不会写代码。这不像自然书面语或口语，理解他人的意思并不需要去理解他们为什么要那样说。比如，如果我说：“写代码有两种方式：一种严格且详细，另一种模糊且草率。前者生成简洁分层的婚礼蛋糕，后者却是意大利面条。”上面这句话产生一个平衡且幽默的效果，但即使听众和读者不理解我使用“零照应”和“并列句”这样的文字技巧，也会理解我要说的意思。但是说到代码，既要从代码本身中理解代码作者的意图，又要理解代码产生的预计效果，这两者都极为重要。因此，我又回到那个问题了，有些人需要快速切入代码，但不需要动手写代码，那我们如何编写适合这些人的代码？下面是我在编写代码时，尽力去做的事，目的就是使其他人能轻松阅读： 使代码遵从工具。Object Browsers和Intellisense虽然很好，但我告诉你，我是守旧派。如果找不到我想要的，我会不高兴。什么使得代码成为可查询的呢? 像i这样的变量名不好。如果没有明确的错误提示，你就无法轻易查找代码。 避免使用是其他名字前缀的名字。比如，在代码中有个“perfExecuteManifest”，如果再有一个“perfExecuteManifestInitialize”，这就会让我抓狂，因为每次在源码中查询前者时，我不得不费力地过滤掉后者所有的实例。 “临时传递数据”（tramp data）应使用相同的名字。所谓“临时传递数据”（tramp data），就是指那些传递给方法A的变量，还要传给方法B的变量。这两类变量实际上是相同的，所以如果它们有着相同的名字，则更好。 别用宏来重命名东西。如果有个方法叫get_MousePosition，那别这样GETTER(MousePosition)来声明该方法。因为我会找不到实际的方法名。 Shadowing会引起很多问题，请不要用它。 坚持使用一种命名模式。如果你打算用匈牙利命名法，那就坚持并广泛使用，否则将适得其反。使用匈牙利命名法来记录数据，而不是存储类型；记录普遍事实，而不是临时条件。 使用断言来记录先决条件（preconditions）和后置条件（postconditions）。 别缩写英文单词。确切来说，别缩写成稀奇古怪的形式。在脚本引擎中，有个变量名叫“NME”，这让我非常抓狂！它应当叫“VariableName”。 C语言标准运行时库的设计不是很优秀。别去效仿它。 别写“聪明”的代码；当代码出现问题，维护代码的程序员没时间去理解你的聪慧。（编注：这条建议即为：编写可维护的代码，详情可参见明星软件工程师的10种特质中的第8点。） 理解编程语言特性的设计初衷，使用这些特性去做它们适合完成的工作，而不是它们能做到的工作。例如：别把异常当做一般的流控制机制来使用（即便你能做到），而应该用它们来报告错误。别强制把接口指针转换成类指针，即便你知道这样没问题。 按功能单元划分源码树，而不是按组织结构。比如：我目前所在团队中，有2个根子目录的名字是“Frameworks”和“Integration”，这是两个团队的名字。不巧的是，Frameworks团队名下有一个叫“Adaptor”的子目录，而“Adaptor”却是Integration的子目录，这就非常令人迷惑。同理，（如果）有着相同子目录的不同的子树，有些是客户端的组件，有些是服务端的组件；有些是管理组件，有些是非管理组件；有些是处理型组件，有些是非处理型组件；有些是零售组件，有些内部测试工具。这就会乱七八糟的。当然，我实际上根本没有回答Jeremy的问题如何调试不是我写的代码？这取决于我的目的。如果我只是因为一个bug，而深挖一段具体的代码，我会在调试器中逐步跟踪所有代码，写下我“走过”的调用分支，记录下哪些方法是特定数据结构的“生产者”，哪些方法是“消费者”；我也会仔细盯着输出窗口，查看出现的有用信息；还要打开异常