代码是用于计算机还是用于人？ [关闭]答案

【问题标题】：Is Code For Computers or for People? [closed]代码是用于计算机还是用于人？ [关闭]
【发布时间】：2010-10-06 02:07:11
【问题描述】：

最终，代码（最终）编译为 CPU 的指令。然而，代码（以我的拙见）是供人类阅读、更新和交互的。这使我得出以下观察结果：

其他工程师无法阅读的代码，即使它是功能性的，也是糟糕的代码。

考虑到这一点，这位程序员可以做些什么来使代码更容易被人类阅读？

命名约定？（乔尔对此有很多话要说）
代码结构/布局？（拜托，看在上帝的份上，不要卷入{ 安置辩论）
措辞？（有没有可能写出更像英文的代码）

除了Joel's之外还有没有好的文章。

【问题讨论】：

标签： code-readability

【解决方案1】：

<sarcasm> 代码只能由机器读取。只要最终结果满足用户的需求，代码长什么样都无所谓。</sarcasm>

现在可维护的代码或可以更改的代码，那是完全不同的故事。

您会在餐巾纸背面写下计划来建造房屋，还是在建造完房屋后扔掉蓝图，您可能想在一天内增加一个房间？

【讨论】：

-1：所有代码都得到维护。
不开玩笑？也许你注意到我的语气中暗示讽刺......
@Chris，实际上，不......我也没有发现讽刺。从您的第一段（恕我直言）来看，这并不明显是讽刺的。我想你的意思是，正如 S.Lott 提到的那样，所有代码都得到维护，但正如第一段所述，它暗示了其他情况（对我而言）。
++ 讽刺讽刺 :-) 谢谢你的笑声。

【解决方案2】：

“任何傻瓜都可以编写出电脑能看懂。好的程序员编写人类可以编写的代码理解。” -- Martin Fowler，“重构：改进现有代码的设计”

但是，既然您已经自己得出了这个结论，那么可以说这是一个巨大的话题。这不是你能得到一个答案的东西。使您的代码可维护不仅限于编码风格，还涉及您的整体设计以及构建过程。以下是本网站上的一些标签，其中几乎所有的问题和答案都会涉及到这个主题：

【讨论】：

在写“任何傻瓜都可以编写计算机可以理解的代码”时，福勒可能是在暗指 Silvanus Phillips Thompson 的 Calculus Made Easy，它在整个世界中都提到了“傻瓜”引言，包括著名的台词“一个傻瓜能做什么，另一个能做”，马丁·加德纳和理查德·费曼都提到过。

【解决方案3】：

我的看法有点切题 - 这不是关于可读性，而是关于可维护性。

阅读只是看着代码并认为您可以阅读它。通常认为，为了可读，它必须对没有努力理解它的人来说是可读的。

维护是进行更改以修复错误或实施新/更改的要求。阅读只是这个过程的一部分。我不知道任何不需要维护者学习曲线的可维护代码，对于没有爬过这条曲线的人来说，代码看起来“不可读”。

同时，我认为教维护者帮助他们攀登学习曲线是程序员责任的一部分。一种方法是留下关于如何执行可以预期的未来变化的分步说明。

我经常看到代码被填充了很多空白，因此不太适合屏幕显示，并且给出了冗长的命名和 gabby cmets。这给人印象的可读性。

【讨论】：

【解决方案4】：

我建议您查看 Robert Martin 的 Clean Code。这是关于如何使您的代码更具可读性和简洁性的绝佳指南。

【讨论】：

【解决方案5】：

Roedy Green 编写了一份详尽的指南，名为：Unmaintainable Code。

“考虑到这一点，这能做什么？程序员做代码更容易被人类阅读？”

答案：阅读本指南并将其内容反过来应用到您的开发活动中。

引自一般原则部分：

“为了挫败维护程序员，你必须了解他的想法。他有你的巨型程序。他没有是时候阅读全部了，更不用说明白它。他想迅速找地方做他的改变，成功并离开，没有意想不到的副作用改变。

他通过厕所查看您的代码纸管。他只能看到一个微小的你的程序的一部分。你想确保他永远无法到达这样做的大局。你想让它尽可能难让他找到他正在寻找的代码为了。但更重要的是，你想要让它尽可能尴尬他安全地忽略任何事情。

程序员陷入困境因惯例而自满。由每偶尔，通过巧妙地违反约定，你强迫他阅读代码的每一行都带有放大镜。

您可能会认为每个语言特性使代码不可维护——不是这样，只有当正确滥用。”

虽然它是一个坚定的舌头，但它实际上是一个非常有用的列表（除了令人讨厌的广告），如果你真的关心编写可读/可维护的代码，应该避免什么。

【讨论】：

【解决方案6】：

编译器不在乎你的代码写得干净还是乱七八糟——只要语法正确，代码就会编译并运行。

然而，在代码维护方面，为人们编写干净的代码将非常有用。从业务案例的角度来看，新程序员理解代码所需的时间越短，让新人跟上进度所需的钱就越少。因此，更干净的代码更有价值。当程序员需要多 100% 的时间来理解不可读的代码时，它的执行速度提高了 5%，这有什么意义呢？毕竟，程序员要花不少钱。

按照样式、变量命名等编码标准编写代码对于保持多人编写的代码一致非常重要。 遵循良好编码标准的一致代码库将更易于维护。

通常，在优化代码时，它可能会变得难以理解，但总的来说，编译器在优化方面已经变得更好，因此编写更清晰的代码也将提高编译器捕获某些构造的机会并对其执行优化，从而提高性能。

为人而不是机器写作。

【讨论】：

【解决方案7】：

程序应该为人而写阅读，并且只是偶然的执行的机器。

--摘自 Abelson 和 Sussman 的“计算机程序的结构和解释”

【讨论】：

太多人误解为：代码的读取次数多于执行次数。
不，我想它的意思很清楚。此外，您编写的代码不仅应该被其他人阅读，而且还应该被未来阅读代码的您（并且会忘记关于它的每一个未成文的细节）阅读。

【解决方案8】：

我对此的看法是，一切都是相对的。

当您需要更改代码时，代码是给您的，当它为机器执行时。

如果代码正常工作，它就有可能被读取。

你的人性和合作精神应该使它易于被其他人阅读，但最终，除了约定之外，代码的可读性有时可能会在旁观者的眼中。

代码越容易被人们阅读，它就越容易被更改和维护，因为进化受益于你对问题应用的贡献/贡献者的数量，这种类型的代码可以比不可读的代码更好地声明.

但最终，代码将被制成一组指令给机器。

人类的意图被翻译成机器可以遵循的东西，因此代码同时适用于两者。

【讨论】：

+1 表示最终，撇开约定不谈，代码的可读性有时可能在旁观者的眼中。

【解决方案9】：

是的。

如果计算机不运行它，它就坏了。如果人们不能阅读它，它就会被破坏。很快。

【讨论】：

我不同意。如果有人看不懂，并不意味着代码被破坏了。如果它被破坏，它真的很难修复，但它本身的可读性并不构成工作代码。
现在。蒂姆，回去再读一遍我说的话。
@Charlie：这是我最喜欢的短语。

【解决方案10】：

不要在类型安全的语言中使用hungarian notation。

【讨论】：

Apps 匈牙利语和 Systems 匈牙利语非常不同。 Apps 匈牙利语没有任何问题，它在许多情况下都非常有用。系统匈牙利语也没有问题......但它的局限性很大。
匈牙利语最初的意思是出于业务逻辑原因为变量添加前缀，例如 screen_x,screen_y 和 window_x,window_y 除非您要为每个变量创建不同的整数类，否则labguage 无济于事
匈牙利符号的最初目的是为变量添加语义类型信息（即“cb”前缀表示缓冲区大小等），不是复制数据类型信息.这就是所谓的应用程序与系统匈牙利语。
不要使用匈牙利符号。时期。用任何语言......从我的高马上走下来......
请不要在和语言中使用匈牙利符号。为了在 PHP 中摆脱它，我进行了很多次斗争。 PHP 是类型安全的语言。 Example 为什么在 firstName 肯定是 String 时写 strFirstName;-)

【解决方案11】：

缺少项目：cmets。

即使代码对其作者来说完全清晰易读，但它可能并不适合所有人。

【讨论】：

您应该以无需 cmets 即可理解的方式编写代码。注释应谨慎使用，仅在真正需要时使用。太多的 cmets 可能比太少的更不可读。