C语言程序员的“八诫”

Answer 1

c语言逞序员的八诫

1.你应经常运行int,并研习其教诲，因为它的直觉和判断通常比你强得多。这一条说得很有道理，然而许多现代编译器也会找出许多同样的错误，Iit本身也由干过时、判断标准不一致或者无法检测未知的领域而导致许多错误。

还有许多像Saber C之类的其他工具也很有用。“经常”的意思是你应该每天聆听其教诲，而不是在最后时刻期待着Iint为代码降下福音。对从来没有int过的程序进行it,其结果通常会造成程序的不稳定，因此应当竭力避免。有人发现，在调试的时候多多关注int的教海，会非常有用。

2.你不应访问NU儿L指针，因为这样只会导致混乱和疯狂。

显然这句箴言抄错了，应该是“空指针”(ulpointer)不是NULL指针(NULL pointer),避免人们把空指针和NU儿L宏混淆。除此之外，这一条无需多解释。空指针指向的位置可能是恶龙、恶魔、coredup,以及数不清的邪恶生物，如果你惊7它们的美梦，它们就会在程序里肆虐横行。空指针并不会指向0或任何类型，尽管一些老旧的代码会做这种假设。

3.你不应将所有函数参数都强制转换为期待的类型，即使你认为无需如此因执，才能避免迟早会到来的报应。程序员应当懂得所用语言的类型结构，才能免遭不幸。与一些人的认知不同，int和long并不是同一种类型。历史上曾有非常短暂的一段时期，int和long的大小和表示是相同的，但有人偏偏笃信这一点，而且这种观点还会一直延续，即使在64位计算机已经流行的现在。

而且，与那些住在污染的东方沼泽（指Uiⅸ的诞生地贝尔实验室)的人们的信仰不同，NU儿L其实并不是指针类型，作为函数参数使用时，必须强制转换成正确的类型才可以。

4.如果头文件没有给库函数定义返回类型，你应该谨慎地自行定义，以避免对程序造成伤害。先知Ansi C还以她的智慧教导我们，你应当鞭答供应商，以驱逐之痛要求他们提供库函数的头文件。毕竟，只有他们才知道使用他们的魔法的正确方式。先知还说，尝试自己给函数添加定义是不智之举，会坠入无尽bug的地狱。

5,你应当检查所有字符串（以及所有数组）的数组边界，因为肯定有人会在该输入00的地方输入supercalifragilisticexpialidocious。正如戒律中提到的超长字符串，这一条戒律的结论就是永远不要使用gets0,因为它是魔鬼的工具。你的接口应当永远将数组边界传达给仆人（指函数），若仆人不遵从，就应当发配到删除之地，使其永远不能为恶。

6,如果一个函数声称在遇到问题时会返回错误码，那么你应当检查错误码，即使这样做会让代码量变成三倍。如果你认为“不会发生在我头上”，那么神一定会惩罚你的傲慢。

真正的信徒都希望更好的错误机制，因为显式检查返回代码非常麻烦，不检查则是最大的诱惑。但在遥远的救赎之日到来之前，你必须耐心谨慎地走过崎岖的小路，否则无论是供应商、机器还是软件，都会在你论文答辩或客户交付日前一天晚上为你送上意想不到的礼物。

7.你应当学习库，尽量不要重新发明，因为库的代码更短、更易懂，能让你更快乐、更有效率。数不清的异教徒对干库持有轻蔑的态度，并且迷信自己能做得更好(“效率更高”)。C库的确有一些功能写得不好，但使用库远远要比自己发明方形的轮子要快、要容易。但是要非常了解库能做什么、不能做什么，避免使用不可靠的功能。

8.不管你喜不喜欢，你应当使用1TBR风格，让程序的目的和结构能被同事理解。你的创造力应该放在解决问题上，而不是放在制造理解障碍上。这条戒律给那些不了解古谚语的新手和饭依者造成了一些怀疑。

1TBR指的是第一代先知布莱恩·克尼汉和丹尼斯·里奇在他们的文章中演示的风格（即K&R风格的变种)。很多人批评这种风格很难用，但实际上它只是有点难学，一旦学会之后就非常清晰易懂，非要说缺点的话，就是有点容易出错而已。