代码风格

“注释尽可能的少。清晰、使用好的命名以及有缩进格式的代码通常就能解释它本身。注释只有在某些时候才有必要，例如数据结构的细节、算法中的特殊情况以及异常情况等等。编译器不能检查注释和代码的一致性，由此可能产生误导的注释比没有注释更糟。最后，那些杂乱的、过多的印刷样式中的注释，除了给代码带来混乱外，其他什么用处也没有。“

——摘自《c语言接口与实现》

刚进部门，开始编码的时候，就遇到了一道选择题：部门中，一部分人希望代码中有大量注释，另一部分人强调用长命名代替注释。我有自己喜欢的命名规则，所以不排斥后者，但是还是希望按照前者进行编码。

在几次开发过后，越来越倾心于后面那种方式，但是，前者还是需要的。

刚入职的新人，写出的代码往往有几个特点：一、无返回值，二、无异常处理，三、无参数，四、喜欢缩写……这时候，要求代码中有大量注释，是必要的，否则，后来维护的人可就要头冒烟了。

需要 返回值 吗？

这得好好斟酌一下，无返回值的一个原因是，该.C文件使用了全局变量或者静态全局变量，没必要使用返回值，只需要检查全局或者静态全局变量就行了。就算不说使用全局变量带来后果（毕竟，有时候使用设计合理的结构体，也是一种比较好的面向对象编程思维），在后者维护的时候，检查代码会导致逻辑不够清晰，挑来跳去的，让人精神崩溃。

需要 异常处理 吗？

往往一个新项目，很多资料都未完整，比如资源只是制作了部分，系统底层提供的API还不成熟，如果系统不提供断言，自己做一个简单的断言来避免也是不错的。

需要 参数 吗？

设置有意义的参数，会给维护者吃一粒定心丸，方便其理解代码含义。

喜欢缩写 有错吗？

没错，因为它节省开发者开发的时间，可是，这后面给维护增加的困难，应该不是开发者所能接受的。




总之，如果我是负责人，我想，对于新入门的攻城师，我会把一大堆新手写的代码让其维护，等一段时间后，再让其维护风格优秀的代码，最好才让其进行新项目的编码……如果没有那段痛苦的经历，就让要求他写出好风格，我想，他是有抵触情绪的……如果有那段经历后，写出的代码还是惨不忍睹，那只能怀疑该攻城师的“良心”了。