原文有图 还蛮好笑的 http://mmdays.wordpress.com/2007/04/24/coding-style/ Posted by Mr. Saturday 写程式的人都或多或少会有这种感觉，别人的code看起来总不是那麽地顺眼，阅读自己的 code才是像阅读好书一样如行云流水般顺畅。其实写 code如写书，不仅写给自己看，同 时也写给别人看；开发软体也往往有如打造一件工艺品，投入其中的巧妙心思及用心，会 影响到最後呈现出来的结果。所以，写程式本身可以是一种艺术，而不仅仅是一件耗费劳 力的枯燥工作。这也是为什麽Knuth要把他的巨着取名为The Art of Computer Programming，他认为打造软体是困难的，是一种复杂度以及最後呈现结果足够作为一件 艺术品的一种过程。当然以Mr. Saturday的观点来看，要迈入如创造艺术品般地去打造软 体这样的一个境界，实在不是我们这种实力浅薄之人一日可成的事。所以，我还是比较喜 欢写code如写书这个切入点。 既然写code如写书，那麽最重要的就莫过於条理清晰，脉络分明的内容了，於是我们就需 要一套令人容易了解的呈现手法来写作了，一方面让自己好读，一方面也让读者好读：於 是coding style这种东西就出现了。这篇文章就是要来跟大家简单介绍一些写code最为常 用的coding style，以及一般programmer彼此之间常常存在的有趣现象。 可能有人会觉得：「coding style这种东西有什麽好谈的？」其实coding style说起来还 真没什麽学问，不过就是写code的一些风格罢了。但是一般programmer常常会忽略的是， 他们写code其实是给三种观众看： * 给compiler看：这是每个programmer都会记得的事情，所以他们会确保自己写出来 的东西不会让compiler抱怨，或是吐出一堆垃圾，因此他们会乖乖地遵循着programming language的语法，好好地写给compiler看，小心翼翼地不要犯错。compiler不会计较你写 code的style，只要compiler 看得懂，就一切ok。 * 给自己看：不幸的是，很多人从头到尾都没想到，写code也要写给自己看，而且不 仅仅是让自己现在看得懂，也要让自己以後看得懂，很多 programmer年轻气盛，在程式 里用了高超的语法和神奇的bitwise technique，写了执行速度快人一等的程式，却就是 忘了写注解，十年後翻开一看，虽然大概知道以前用的技巧和语法，却要重新咀嚼一番才 能完全理解，想想如果此时十年前的你可以来跟你解释，不是挺好？所以别忘了把自己也 当成是潜在的读者。 * 给其他人看：project的deadline快到了，只剩没几天可以赶code，还要算算整个 程式兜起来compile所需要花的时间，现在这种情况下，能有东西交差就不错了，还管什 麽style和注解啊。ok，连夜赶工过了几天终於写完了，但是下一个project又接踵而至， 哪还有时间回头去把code好好重新整理一番？注解？等我有空再说吧。(结果真的有空了 也跑去上MSN聊天) 於是在业界，我们往往就会看到一大堆没有注解和coding style混乱的code，一打开档案 ，我们嘴里就开始不停咒骂这些该死不写注解、还以为全世界的人都有义务看得懂他的 code的宅男。然後一年後，换成另外一批人在咒骂我们。软体界就是如此生生不息。根据 业界的统计，一个软体的生命周期之中，有80%是花在维护上面，让他人容易读懂和维护 你的code，对於软体的成功和演进至关重要。Mr. Saturday曾经接到一个有关Robotics的 专案，是要写机器人运作的软体，这个软体之中有关kinematics的部分已经完成了，我要 负责做的是search的演算法，但是search过程中总是需要去度量机器人现在的kinematics ，於是乎我打开了前人写好的部分，准备好好研究一番。结果一看不得了，几十个 source code的档案，加一加三千多行的程式码，显然出自於多人之手，不仅coding style混乱，更糟的是注解不超过10行！一看真是整个呆掉，写信去问之前的开发者也是 久久没有回音。(其实就算得到回音，我还真的是不知道要从何问起。)结果最後就演变成 ，我和我的team member另外写code去猜和测试这些没有注解的程式是在做什麽！真是有 够心酸。脑细胞也因此坏死一堆。 在业界一些比较大型的软体公司，自然会有一套方法来避免这种现象，所以coding standard应运而生。作为一个新进人员，阅读公司制定出来的coding standard绝对是新 进训练时不可或缺的一环。如果公司自始至终都没有给你看内部惯用的coding standard ，那这家公司的软体开发水准，恐怕就要画上一个问号了。如果你现在只是一个自学程式 ，写写学校作业和project的学生，培养好的 coding style对你来说同样重要，因为业界 很多的自订标准，脱离不了一些经典的coding style，以下简单列出一些给大家参考： * Coding Conventions for the Java Programming Language * C++ Programming Conventions * Pascal Style Guide * Mozilla Coding Style Guide * Linux Coding Style * Hungarian Notation: 这个要特别讲一下，这是微软在1980年代搞出来的一种取名 方式，如果你看过Win32 API或是现在还在跟MFC奋战的话，你对於这个notation一定不会 陌生。这种style引起相当大的争议，因为程式之中会出现一些名字相当怪异的变数或是 class名称，看起来很丑。所以除非你有志跟微软的那些东西长期相处，不然我个人是觉 得平常写程式实在没有必要学这种notation。 Coding Style没有绝对的好与坏。一但你选定自己遵循的规则後，之後最重要的就是维持 这个style的一致性，不要变来变去。 另外，不仅仅是针对programmer而已，coding style对於project manager有时甚至更重 要，你身为一个project manager，绝对不能让自己手下几个programmer在coding style 上有各自为阵的机会，如此一来整个专案将会非常难以维护，programmer彼此之间用code 来进行的沟通也会遇到阻碍，最後完成的软体看起来也会像是拼拼凑凑出来的乐高，相当 不专业。因此，在专案初期，根据公司普遍的标准制定该专案的coding style是相当重要 的一件事情，此时就有几件事情需要考虑： * 有几个coder参与这个专案 * 他们平常的coding style是如何，注意那些喜欢写怪code的人 * 制订出一个大家都满意的coding standard，至少要取得共识 * 明确规范coding style，包括缩排、大小写、括号的位置以及注解的型式等等，都 要有简单的范例和规章来明确说明 * 定期追踪他们写出来的东西，不要让他们的code随着时间渐渐偏离订好的coding standard 好的coding style是建构软体相当重要的前置作业，现在的project鲜少是由一人独力完 成，以同样的coding style来达到离线沟通的目的就显得更为重要。而当我们写程式时， 最重要的认知就是我们写出来的软体，是要给别人和自己维护的，不是写完可以跑就算了 ，记住要和大家取得写程式共识，不要觉得写到别人看不懂才能证明自己的功力高深。写 大家都看不懂的东西谁都会，但是写到每个人都可以看得懂就真正是一门大学问了。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 125.225.111.214