代码风格的关键

下列代码格式方面的规则摘自Kernighan和Plauger著、McGrawHill出版的书籍《代码风格的关键》。书中有这样一段话:“套用Strunk和White的观点,代码的格式和英语的格式一样,总免不了被破坏——哪怕是最好的程序员或作家。一旦规则被破坏,你往往需要在程序中找个地方做点弥补,以抵消由此带来的损失。除非你已经做得够好了,否则你可能需要用下面的要素来要求自己做到最好。”

-----------------------------------------------------

1.   把代码写清楚——不要耍小聪明而把代码写得太过“巧妙”。

2.   说清楚你的意思,并且简明、直接。

3.   在任何可行的时机使用函数库。

4.   避免过多的临时变量。

5.   把代码写清楚——不要以牺牲可读性为代价来优化所谓的“效率”。

6.   让机器去完成那些烦人的工作。

7.   把可重复利用的代码抽象成公共的函数。

8.   利用括号避免语法上的误会。

9.   选用不会产生误解和混乱的变量名。

10.  避免没有必要的代码分支(branch)。

11.  如果一个表达式的逻辑不容易理解,则需要试着改变其形式。

12.  选择一个简明的方式展现数据。

13.  先写出简单易懂的伪代码,再将其“翻译”成你要使用的程序语言。

14.  模块化编程。

15.  如果你想保持程序的可读性,请杜绝使用goto语句。

16.  别给烂代码打补丁——直接把它重写。

17.  将一个大块的程序分解成几个小部分进行编写和测试。

18.  为递归定义的数据结构使用递归的程序。

19.  验证输入的合理性和有效性。

20.  确定输入是否超出了程序规定的范围。

21.  用特定的休止符作为识别用户输入是否结束的标志,而非限制输入的字数或长度。

22.  辨识错误的输入,可能的话最好能对其进行恢复。

23.  为输入做好准备,使输出可以不言自明。

24.  使用一致的输入格式。

25.  令输入易于校正。

26.  使用自我识别的输入。允许默认输入。且这两者都在输出端有所回应。

27.  确定所有的变量在使用之前都进行了初始化。

28.  不要一直纠结在一个bug上。

29.  使用调试编译器。

30.  小心“从一开始”(off-by-one)的错误。

31.  确保代码分支在正确的方向上。

32.  小心一个循环中有多段代码可以跳往同一个地方的情况。

33.  确认你的代码做任何事情都是优雅的。

34.  在程序自己的界限标准内进行测试。

35.  手动检查一些问题。

36.  10.0乘以0.1不等于1.0。

37.  7/8为0但7.0/8.0不为0。

38.  不要比较两个浮点数是否相等

39.  在做性能优化之前,先确定它是正确的。

40.  在做性能优化之前,先确定它是安全可靠的。

41.  在做性能优化之前,先确定它的代码是清晰的。

43.  用你的编译器完成简单的优化。

44.  不要过度重用代码,而是通过重新整理代码来完成重用。

45.  确定那些特殊情况真的是“特殊”的。

46.  让性能优化变得简单。

47.  不要通过偷工减料来优化性能——而是要寻求更好的算法。

48.  评估你的程序。在进行"优化"之前进行测量。

49.  确定代码和注释是匹配的。

50.  不要用重复代码的形式写注释——让每个注释都有意义。

51.  别为烂代码写注释——直接把它重写。

52.  使用有语义的变量名。

53.  使用有语义的语句标签。

54.  将程序格式化以帮助读者理解。

55.  将数据模型写成文档。

56.  不要过度注释。 

你可能感兴趣的:(代码)