30

最终,代码(最终)编译成 CPU 的指令。然而,代码(以我的拙见)是供人类阅读、更新和交互的。这使我得出以下观察结果:

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

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

  • 命名约定?(乔尔对此有很多话要说)

  • 代码结构/布局?(拜托,看在上帝的份上,不要卷入{位置辩论)

  • 措辞?(是否可以编写看起来更像英语的代码)

除了Joel 的文章之外,还有其他好的文章吗?

4

11 回答 11

66

是的。

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

于 2009-02-07T00:56:57.090 回答
50

“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。” ——Martin Fowler,“重构:改进现有代码的设计”

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

于 2009-02-07T01:33:40.120 回答
28

程序应该写给人们阅读,并且只是偶然地让机器执行。

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

于 2009-02-07T01:29:07.510 回答
14

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

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

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

通常,当涉及到优化代码时,它可能会变成一团难以理解的混乱,但总的来说,现在编译器在优化方面已经变得更好,因此编写更清晰的代码也将提高编译器捕获某些构造并执行优化的机会在它上面,从而提高性能。

为人而不是机器写作。

于 2009-02-07T01:33:24.490 回答
5

Roedy Green 写了一份详尽的指南,名为:不可维护的代码

“考虑到这一点,这个程序员可以做些什么来让代码更容易被人类阅读?”

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

引用一般原则部分:

“要挫败维护程序员,你必须了解他的想法。他有你的巨大程序。他没有时间阅读它,更不用说理解它了。他想快速找到进行更改的地方,制作它并走出去,不会因为改变而产生意想不到的副作用。

他通过卫生纸管查看您的代码。他一次只能看到你程序的一小部分。你要确保他永远无法通过这样做来了解全局。你想让他尽可能难找到他正在寻找的代码。但更重要的是,你想让他安全地忽略任何事情变得尽可能尴尬。

程序员因惯例而自满。每隔一段时间,通过巧妙地违反惯例,你强迫他用放大镜阅读你的每一行代码。

你可能会认为每一种语言特性都会使代码无法维护——不是这样,只有在被正确滥用的情况下。”

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

于 2009-02-07T01:31:12.013 回答
5

我对它的看法有点切题——这不是关于可读性,而是关于可维护性。

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

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

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

我经常看到被空白填充的代码,因此不太适合在屏幕上显示,并且给出了冗长的命名和冗长的注释。这给人以可读性的印象

于 2009-09-18T15:17:40.147 回答
4

<sarcasm>代码只能由机器读取。只要最终结果满足用户的需求,代码看起来如何并不重要。</sarcasm>

现在可维护的代码或可以更改的代码,这是一个完全不同的故事。

你会在餐巾纸背面写下一个计划来建造一所房子,还是在你建造完一所房子后扔掉蓝图,你可能想在一天内增加一个房间?

于 2009-02-07T00:58:20.223 回答
3

我建议看一下Robert Martin 的Clean Code。这是关于如何使您的代码更具可读性和简洁性的一个很好的指南。

于 2009-06-01T19:05:41.923 回答
2

不要在类型安全的语言中使用匈牙利符号。

于 2009-02-07T00:58:58.037 回答
2

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

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

如果代码正常工作,它就有被读取的潜力。

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

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

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

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

于 2009-02-07T01:21:56.010 回答
1

缺少的项目:评论。

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

于 2009-02-07T00:56:54.080 回答