相关语录

整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

也不必用m_前缀来标明成员变量。应当把类和函数做的足够小，消除对成员前缀的需要。你应该使用某种可以高亮或用颜色标出成员的编辑环境。此外，人们很快学会无视前缀（或后缀），只看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。

重视小处，小处要诚实。对代码诚实、对同僚坦承代码现状，最重要的是在代码问题上不自欺。是否已尽全力“把露营地清理得比来时还干净”？签入代码前是否已做重构？

让读的过程变得轻松，即便那会使得编写过程更难。编写代码的难度，取决于读周边代码的难度。

宏大建筑中最细小的部分，比如关不紧的门、有点儿没铺平的地板，甚至是凌乱的桌面，都会将整个大局的魅力毁灭殆尽。这就是整洁代码之所系。即便是在汽车工业立，大量工作也并不在于生产而在于维护——或避免维护。

借用美国童子军一条简单的军规，应用到我们的专业领域：让营地比你来时更干净。如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：•能通过所有测试；•没有重复代码；•体现系统中的全部设计理念；•包括尽量少的实体，比如类、方法、函数等。在以上诸项中，我最在意代码重复。如果同一段代码反复出现，就表示某种想法未在代码中得到良好的体现。我尽力去找出到底那是什么，然后再尽力更清晰地表达出来。

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新一天。我们都曾经看到自己的烂代码居然能运行，然后断言能运行的烂程序总比没有强。我们都曾经说过有朝一日再回头清理。当然，那些日子里，我们都没听过LawofLeBlanc：Laterequalsnever

如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。

我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

顺势而为才能避免危险，有所成就。