小结
标准化那些确实有必要标准化的内容，不要加入任何个人喜好，也不要在标准中加入那些已经过时的规则。
讨论
纯粹反映个人喜好的观点和不影响程序正确性和可读性的规则都不应该出现在程序代码标准中。对于与他们自己使用的代码格式稍有不同的代码，任何有经验的程序员都能轻松应对。
源文件中风格不一致的代码会弄得程序员焦头乱额，因此在每一个源文件和整个项目中尽量应该使用一致的格式；但是，对于多个项目或者使整个公司而言，都要求采用一致的格式就有点过犹不及了。
下面我们就看看一些不适合规定为标准，但是应该注意保证一致性的问题：
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" />
1 void using_k_and_r_style() {
2 // …
3 }
4
5 void putting_each_brace_on_its_own_line()
6 {
7 // …
8 }
9
10 void or_putting_each_brace_on_its_own_line_indented()
11 {
12 // …
13 }
14
15
上面的三种括号布局方式在可读性方面没有任何的差别，任何有经验的程序员都能不费吹灰之力地读写他们，因此对于括号布局方式的选择，你选取任何一种均可，但一定要注意，在你的代码中要保证一致性。
2) 空格和制表符(tabs)
由于制表符在各个编译器间表现各异，如果误用，甚至可能导致本应该缩进的代码反而缩出或者是毫无功效，因此，很多团队禁止使用制表符。即使有些团队允许使用制表符，他们也经常会作出严格的规定以避免使用制表符可能带来的缺陷。如果你使用制表符，请确保不要以减弱代码的清晰度和加大团队成员对你的代码的阅读难度为代价。如果你不使用制表符，允许其他人在阅读代码时能使用编辑器将空格转换为制表符，同时确保他们修改文件后保存时使用编辑器将制表符转换为空格。
3) 匈牙利标记法
采用匈牙利标记法能将类型信息加入到变量名中，对于类型不安全的语言（c语言为代表）来说，可能会十分有用。但对于面向对象语言而言，虽然也能采用这种命名法，却不能带来任何好处。在泛型编程中，甚至根本就不能采用这种标记法来命名变量。因此，没有任何C＋＋编码会要求必须使用匈牙利标记法，甚至有些团队禁止采用这种标记法。
4) 单入口，单出口（SESE）
以前，确实有些编码标准要求一个函数只有一个出口，亦即只有一个return语句。但这种规则在现如今支持异常和析构函数的语言中已经是明日黄花，早已过时了。
转载于:https://www.cnblogs.com/lotusswan/archive/2005/09/04/229793.html