糟糕的代码设计真的让人很心烦..

把注释直接变成方法名
短方法不是为了复用，而是为了清晰思路。复用是一个顺便得到的好处。
一个描述太多细节的方法是没有美感的。我前面就说了，人在同一时间能思考的元素不超过7个。让阅读者第一时间了解这个方法在做什么，这样的方法才是有美感的。
而且反正你也花一分钟来写注释了，那为什么不把代码本身变得能够一眼看懂？
注释是冗余的信息。将来修改代码的同时还要修改注释。信息冗余是没有美感的。
我承认这些很大程度上是审美。不过熵是强大的，有时候没有一点对美感的偏执你会很难和熵做斗争。
这就是为什么那么多项目最终腐化到不能维护的原因。

平均5行一个方法可能仅限于基于ruby的项目
在某些场景下 过多的方法调用会导致性能下降

注释的作用在某些时候是不可替代的
譬如在修改某个bug的时候，程序员发现必须让某个线程等待1毫秒，但是调用usleep在这里又因为性能和精确度或其它的问题不能使用，于是该程序员写了个循环。
如果这里不写句注释，以后的读者看到了会猜测这是为了延时，但是如果有句注释就可以省却一番猜测和验证。
另外一个选择是写个方法叫delay_one_ms，然后调用此方法。但这对我来说这无异于脱裤子放屁，同时，这也会带来额外的性能损失。

而且在现实中，很多方法是没法写得简单到一眼被看透的
譬如初始化一个skbuf，必然会牵扯到好几层的header的填充，附加很多checksum，异常处理等等辅助工作。
读者可以预测到有这些工作要做，但是只有跟到每一行，才能逐渐展开整个过程。

我想说的是，美感是不可或缺的，但是过犹不及这个道理的优先级更高。
稍稍把眼光放远一点，就会发现很多跟你的认识相悖的事实存在。

绝大多数情况下性能问题发生在IO边际
数据库和网络延迟
因为编程语言的内存运算导致的性能问题，不到千分之一

我不知道为什么不应该这样做
还是这句话，你有工夫写一句冗余信息的注释，为什么不把这个事情变成一个方法？
当然这个方法名显然应该叫delay(ms)或者sleep(ms)，因为如果这个方法只能等待1毫秒不能等待2毫秒的话那是很蠢的想法
而且一次方法调用的时间开销是微秒级的
你要做的事情是等待1毫秒，你却在讨论一个微秒级的性能损失，我觉得这才叫没话找话
而且线程之间的同步不能靠等待，得靠消息
这东西本身就不可靠，不是说你能精确等待1毫秒他就会变得可靠的

事实是我从来没有看到过因为把代码写得更漂亮而遭受损失的程序员，满大街都是被烂代码郁闷到的程序员
过犹不及？huh？我怎么就没见过任何一家中国的软件公司有把代码写得“过于漂亮”的呢？
我孤陋，你给我举个例子吧。
我在一家全球领先的电信设备提供商做咨询的时候，这种话听得耳朵里都起茧子
一边被烂代码郁闷得要死，一边说“过犹不及”，“你们这样的要求不切实际”。那怎么办呢，你都知道该怎么做了，你都知道怎么做才切合实际了，那为什么你还有那么一大堆烂代码砸在手上？
结果我每天跟他们的程序员pair，一个月，然后他们发现原来他们也能做到，他们做到了也有好处。
还是我早就说的，这些事情既然我这么说，我肯定是认真想过做过的。说着“过犹不及”这类永远不会错的废话的人们，你在项目里这样做过吗？你坚持过每个方法不超过5行（或者放松点，10行）吗？你坚持过任何两行以上的代码不重复吗？你坚持过任何超过一行或者两个条件的代码必须有测试吗？如果你没有一段时间坚持过这些最严格的要求，你怎么会知道到底哪里才算是“过”？

我相信我们这两种做法，可理解性是在同一个级别的，而你是执着于小方法，而我觉得合理的注释加上不大的方法。你力求做到完美的一致性，而我是实用主义，满足可理解性。事实上，那种较长的，内部分代码段注释的方法也不是很多的。坚持的哲学不一样。

to giggx:你说你坚持这些的目标是为了什么？高标准是挺好，但是成本也高。我只是觉得你有点偏执，是不是你觉得这样咨询才能给人以权威，才能严要求，即使做不到全部，也能较大的提高代码质量。

我的目标和哲学是坚持可理解性，在此原则上，可以不管那些生硬的原则，事实上，这也是最容易让程序员接受的。
代码只要可理解，优化，重构，维护都非常的方便，让你拥有自由。总之，不必过于教条，尽管如此教条也是通向代码可理解性的一种方式。 你的极致小方法哲学只代表了你的世界观而已。

纯属讨论，言语冒犯之处，尽请谅解。

这个也没什么好讨论的，你自己去给几个这样的团队做一做教练你就知道，讲哲学，行不通，教练一走了这些实践就要走样。
所谓全程质量保证，说白了就是画好框框，这件事情就这样做那件事情就那样做，大家不要讨论不要琢磨，就是这样做。只有这样你才能保证质量不走样。讲哲学，提高团队素质，让大家都想通，都上层次，那当然是好事，如果能做到的话。
这种事情你作为一个team leader和作为一个consultant你思考的角度不能一样。一个别人的团队有这种问题，你不知道这个团队里有什么人，你不知道他们是什么状况。你能做的就是告诉他一条可行的路，只要你走就一定走到什么地方。讲哲学，最后你会得到一个最坏的结果。

楼上某人说你钻牛角尖，可我觉得有时候也许我比你更钻牛角尖。
微秒级的损失和误差对你来说是边界情况，或者是可以忽略的情况，可在我的日常工作中，这是必须考虑在内的。10us和30us是完全不同的。
数据库？那东西太慢了，即使是内存数据库都不够快。我得把存储和搜索搬到内核里去。
IO是重点考察对象，因为即使是我做的玩具，在普通台式机上，都支持1G bps的流量，其中包括L3的重组。当然，这也是在内核里达到的。
你眼中的美，你做的坚持，是代码_看_上去是否美，一个方法是否超过5行。
我坚持的则是更大的并发，更小的性能损失。
我相信你的理念和做法，在你的领域内，会带来工作效率的提升。
但是我想提醒你的是，即使都是写代码，也有不同的领域，你的准则不是处处通行的。
举个例子，你可以统计一下，哪怕是30年前的最最简单的unix，有多少比例的方法是少于5行的？

对这个解释，我的理解是，consultant的assumption是把对方当无脑儿。

六个西格玛，丰田制造，所有被证明有效的流程，第一步都是严格规范质量标准，每个生产环节控制缺陷，全流程质量保障。一切的持续改进都建立在严格保障的基础上。基本的质量保障都做不到就奢谈什么编程的哲学，那是浮沙上建高台。你说我把别人当无脑儿也好怎么也好，至少我做对他们有用的事，而不是说一些对他们没有帮助的漂亮话。

永远正确的废话。
那么好吧，既然你喜欢，我很乐意给我的观点加上限制条件。
我所了解的最佳实践主要适用于商用软件开发。对于电信级高性能领域的最佳实践，本人欠奉。
如果楼上的全都是做电信级高性能程序的，那我就不参与讨论了，没这方面经验。