对程序员的一点建议

对程序员的一点建议

　

柳鲲鹏

2008-3-23

　

关键字：程序员 建议

简介：作为程序员，自己的一点感想：严于编程，象写文章一样写程序；肯于学习；善于思考，把今天的工作挪到明天去。

　

　

　　当一个程序员够辛苦的，可是为了生存也只能忍受，其实这年头除了当官的发财的哪个不辛苦啊。此文是吾很久以前写的东西，今天整理一下发布出来。希望同行们能够共同进步，为中国的软件事业做出贡献。

　　

　　严于编程

　　这个意思就是对自己的编程风格严格要求，不能随便凑合。很多水平不错的程序员编写的程序显得很杂乱，难于阅读，往往仅仅满足于“只要实现要求的功能就行了”。这样对于维护和二次开发都非常不利，也不是一个高明程序员的作风。实际上，编程跟写文章有同样的道理，听吾一一道来。

• 段落清楚

　　大家知道，如果一篇文章没有段落，恐怕无人能够读下去。在程序中呢，如果感到几个语句完成了一个相对独立的功能，不妨就加一个回车来分隔一下。

• 语句易读

　　有一次一个同事向吾炫耀说：我一行程序有200多个字符，很爽。其实这是一个不好的习惯。这一行如果读起来，恐怕不知道有多费事。一般地，推荐使用短语句，如果一个语句确实很长，就分行书写。由于现在程序的发展和缩进的使用，一行的字符数（不包括空格）不超过150较好。

　　

• 层次分明

　　不少人编程时写到哪儿是哪儿，一点也体现不出层次关系。如果两个语句是并列关系，那么它们的语句头应当对齐；否则，从属语句应该多空出一点以体现它们之间的关系。当然，最好能够固定下空出来的数目。

　　另外，有的人喜欢把起始标志写在一个语句的末尾（在if语句的最后添加{}。这样做的结果势必使人难以判断该部分的起始位置，自然就难以阅读啦。所以也建议把这些起始标志单独列行。

　　

• 多加注释

　　多加注释并一定是好事，注释应该加在应该出现的地方。什么地方呢？自己困惑的地方，某些看起来比较奇怪的地方，别人可能难以理解的地方，有技巧的地方。

　　实际上吾不建议写文档。文档只有在研究什么问题的时候才有用。那些解释程序如何运行的文档，从来也没有人看过，至少从来没有人仔细看过，也没有人能够看得明白。一个常见的现象是：半年之后看自己写的文档，也看不明白了，必须对照程序才知道

　　

• 模块独立

　　这个问题，最好学习一下有关方面的书籍，这里就不多罗嗦啦。

　　

　　肯于学习

　　俗话有云：有容乃大。可一些程序员会了一点东西以后，很快就自吾膨胀起来，觉得自己很了不起，什么问题都能解决（说句实话，吾也曾经这样来过）。其实，由于个人接触的内容和范围不同，都有自己的长处。发现自己不会的地方，应当认真请教别人；就是自己的长处，也该谦虚一些，切不可目高于顶。

　　而且，很多程序员的确忽略了向别人请教和讨论。列位，是不是啊？

　

　　勤于思考

　　因为汝不是天才，当然吾也不是。吾首次提出，要想作好工作，就应当把今天的工作挪到明天去，这样今天有充分的时间思考并编好当前的部分。当然，天才们可以今天做明天的事。那么什么样的人算天才呢？

　　譬如有一个人10天写了6万行程序，其实吾也能做到。但是大家都明白，明天的事情就是修正无数的错误。而天才们就几乎没有什么错误，等于一天做了吾两天甚至更多的事情。吾认为绝大多数人无法做到这一点，所以干脆就不要贪多。

　　

　　善于表现

　　这可是大问题。可是现在许多老板看问题的态度不同。他们认为天天加班的必然强于那些按时完成的。而且很多老板喜欢拍马胜过工作，出了问题也不想派心腹们出力（比如吾以前所在的公司就是如此）。如果老板的心腹们都是这样，那还是考虑换一个地方的好。