小结
标准化那些确实有必要标准化的内容，不要加入任何个人喜好，也不要在标准中加入那些已经过时的规则。
讨论
纯粹反映个人喜好的观点和不影响程序正确性和可读性的规则都不应该出现在程序代码标准中。对于与他们自己使用的代码格式稍有不同的代码，任何有经验的程序员都能轻松应对。
源文件中风格不一致的代码会弄得程序员焦头乱额，因此在每一个源文件和整个项目中尽量应该使用一致的格式；但是，对于多个项目或者使整个公司而言，都要求采用一致的格式就有点过犹不及了。
下面我们就看看一些不适合规定为标准，但是应该注意保证一致性的问题：
1) 尽量采用缩进来反应程序结构，但不必规定缩进的具体字符数：使用你中意的任何数目的空格来进行缩进，但至少应该保证每个文件中都采用一致的缩进风格。
2) 使用合适的代码长度，使代码具有可读性，但不必强行规定每一行的代码长度：使用你喜欢的长度来书写代码，但不能过长或是过短以免影响代码的可读性。研究表明，每一行代码具有10个左右的单词最适合于阅读。
3) 采用一致的命名格式，但不必强行指定命名格式：关于这个问题，有两点需要注意：
a) 避免使用underhanded names，就是那些以下划线开始或是包含两个下划线的名字，这些名字通常保留作为编译器专用或是实现标准程序库时使用。
b) 对于宏（macros）不要采用没有特别含义的普通单词，也不要采用缩写形式，而应该采用大写所有字母的完整单词来表示。对函数、变量等命名时，尽量采用有意义的单词来命名，并确保命名风格。
如果你不能确定采用何种命名风格，可以考虑如下的命名方式：
a) 对于类、函数、枚举命名方式：LikeThis；
b) 对于变量命名：likeThis；
c) 对于私有成员变量：likeThis_；
d) 对于宏：LIKE_THIS。
4) 对程序给出有意义的注释时，注释时除了编译器生成的特定格式的注释外，不必规定注释风格：对于程序代码，尽量写下那些能够描述程序意图或是程序采用的基本原理的注释，而不要重复代码，后者对于代码而言毫无意义。
最后，不要使用那些过时的规则，即使他们以前出现在旧的标准中，甚或是风光一时。
例子
1) 括号布局：<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
别为小事抓狂
相关推荐