制在 9 到 15 或者 10 到 16 个字符。它强调的是,如果你查看 自己写的代码时发现了很多更短的名字,那么需要认真检查,确保这些名字含义足够清晰。 子程序名 好的子程序名字能清晰地描述子程序所做的一切。 《代码大全》第 7.3 节列举并详细说 明了若干条指导
原则:描述子
程序所做的所有事情,避免使用无意义的、模糊或表述不清的 动词,不要仅通过数字来形成不同的子程序名字,根据需要确定子程序名字的长度,给函数 命名时要对返回值有所描述,给过程起名时使用语气强烈的动词加宾语[3]的形式,准确使 用对仗词,为
常用操作确立命名规则等。 类名 类的名称应该表达了其中心目的,准确的描述该类的接口所模塑的抽象概念(第 5.3 节),一般用名词。 无论如何, 命名不是一锤子买卖, 一旦发现有更好的名称, 借助现代的 IDE 工具 (Eclipse 或 Visual Studio 2005),我们很容易对变量、常量、类、子程序进行重命名(rename), 这恐怕也是用得最多的一项重构操作了。
第四格式与规范
《代码大全》第 31 章专门介绍代码的布局与风格,前面提到过,编码规范最有用之处 在于让你避免做出武断决定,避免把时间花在无谓的争执上(第 34.5 节)。McConnell 并 不像一位“家具警察”那样对待代码的格式,他认为好的代码布局应凸现程序的逻辑结构, 使代码易于阅读、理解、检查及修改。至于循环体应该缩进几个空格,大括号的摆放位置这 些
问题,正确答案不止一种。每次回答同样内容比起只是回答正确更重要。 第 28.5 节谈到了程序员的信仰问题,缩进风格、大括号的摆放位置、注释风格、命名 习惯、对 goto 的使用、对全局变量的使用等等都是十分敏感的话题。关于这种问题,我觉 得 Herb Sutter 和 Andrei Alexandrescu 的观点更贴近程序员的想法[SA04, Item 0]。 那些“仅仅是个人品味、而不影响正确性或可读性的”议题不应出现在编码标准中。任 何一个专业的程序员都应该能轻易地阅读并编写 “那种格式与自己的习惯略有不同的” 代码。 每个源文件(甚至每个项目)内确保采用一致的编排格式,因为在同一块代码中切换若 干种风格是很不和谐的。但是不要试图对多个项目(甚至对整个公司)强制使用相同的编排 格式。 ……重要的不是设定格式规则,而仅仅是与“你维护的文件中已经采用的”格式保持一 致。 ■ ■ ■ 不要指明缩进多少字符,但缩进要显出结构:你愿意用多少个空格来缩排都行, 但至少每个文件保持一致。 不要规定每行的长度,但确保可读性:你愿意每行多长就多长,只要别太过分就 行。研究表明,最适合人眼阅读的情况是每行不超过 10 个单词。 不要规定注释的风格(某些工具将特定风格的注释提取为
文档的情况除外),但 一定编写有用的注释:只要有可能,尽量以代码代替注解。不要编写与代码重复的 注解;这些注解会逐渐变得与代码不同步。一定编写说明性的注解,
以解释所用的 方法和基本原理。
…… 关于大括号的摆放,以下数种做法在可读性上没有区别: void using_k_and_r_style() { // ... } void putting_each_brace_on_its_own_line() { // ... } void or_putting_each_brace_on_its_own_line_indented() { // ... } 每个专业的程序员都能毫无困难地阅读并编写以上任何一种风格的代码。 但一定要保持 一致:不要随意放置大括号,不要让作用域的嵌套关系变得混淆,并尽量遵循各个文件已有 的风格。
如果你已经知道什么样的代码才是高质量的,那么怎样才能编写出这种代码呢? McConnell 认为,好习惯很重要,因为程序员做的大部分事情都是无意识完成的(第 33.9 节)。例如,你曾想过该如何格式化缩进的循环体,但现在每当写新的循环体时就不再去想 了,而以习惯的方式来做。对程序格式的方方面面几乎都是如此。你