最终,代码将(最终)编译成CPU的指令.然而,代码(以我的拙见)是为了让人类阅读,更新和互动.这引出了以下观察:
其他工程师无法读取的代码,即使它的功能正常,也是错误的代码.
考虑到这一点,这个程序员可以做些什么来使人们更容易阅读代码？
命名约定？(乔尔有相当多的说法)
代码结构/布局？(请为了上帝的爱,不要进入{安置辩论)
分句？(是否可以编写看起来更像英语的代码)
Cha*_*tin 59
是.
如果计算机没有运行它,它就会坏掉.如果人们无法阅读它,它将被打破.不久.
Ada*_*ire 46
"任何傻瓜都可以编写计算机可以理解的代码.优秀的程序员编写人类可以理解的代码." - Martin Fowler,"重构:改进现有代码的设计"
但既然你已经自己得出了这个结论,那么就足以说这是一个很大的话题.这不是你能得到一个单一答案的东西.使代码可维护不仅限于编码风格,还涉及您的整体设计和构建过程.这是网站上的一些标签,几乎所有的问题和答案都会影响到这个主题:
jal*_*ert 28
程序应该编写供人们阅读,并且只是偶然为机器执行.
- 来自Abelson和Sussman的"计算机程序的结构和解释"
coo*_*ird 12
编译器不关心你的代码是干净的还是不可读的 - 只要语法正确,代码就会编译并运行.
但是,在维护代码时,为人们编写干净的代码将非常有用.从业务案例的角度来看,理解新程序员代码所需的时间越短,使新人加快速度所需的资金就越少.因此,更清洁的代码更有价值.当程序员需要100%的时间来理解时,不可读代码的执行速度提高5%是什么意思？毕竟,程序员花了不少钱.
编写以下编码标准样式,变量命名的代码,这样在保持由多人编写的代码是重要的一致.遵循良好编码标准的一致代码库将更易于维护.
通常,在优化代码时,它可能会变成一个难以理解的混乱,但通常,编译器现在在优化方面变得更好,因此编写更清晰的代码也将提高编译器捕获某些构造并执行优化的机会在它上面,可以提高性能.
写给人,而不是机器.
罗迪·格林（Roedy Green）撰写了详尽的指南，名为：不可维护的代码。
“考虑到这一点，该程序员可以做些什么来使人们更容易阅读代码？”
答案：阅读本指南，并将其说明的相反内容应用于您的开发活动。
引用一般原则部分：
“要挫败维护程序员，您必须了解他的想法。他拥有大型程序。他没有时间阅读全部内容，更不用说理解它了。他想迅速找到进行更改，进行更改和更改的地方。摆脱这种变化，并且不会有意外的副作用。
他通过卫生纸管查看您的代码。他一次只能看到您程序的一小部分。您想确保他永远不会从那张蓝图上了解到。您想让他尽可能难找到他要寻找的代码。但更重要的是，您要让他安全地忽略任何事情变得尽可能尴尬。
习惯使程序员感到沾沾自喜。通过不时地违反惯例，您迫使他用放大镜阅读代码的每一行。
您可能会想到，每种语言功能都会使代码无法维护-并非如此，只有正确地使用了代码。”
尽管这是一句坚定的话，但实际上，它是一个非常有用的列表（除了令人讨厌的广告），如果您真正在乎编写可读/可维护的代码，该如何避免。
我对它的看法有点切题——这不是关于可读性，而是关于可维护性。
阅读只是看着代码并认为您可以阅读它。通常认为，为了可读，它必须对不努力理解它的人可读。
维护是进行更改以修复错误或实现新的/更改的需求。阅读只是这个过程的一部分。我不知道任何不需要维护者学习曲线的可维护代码，对于没有爬上这条曲线的人来说，代码看起来“不可读”。
同时，我认为教维护者帮助他们攀登学习曲线是程序员职责的一部分。一种方法是留下有关如何执行可预期的未来变化的分步说明。
我经常看到充斥着空白的代码，以至于它在屏幕上的适应度降低，并且给出了冗长的命名和花言巧语的注释。这给人一种可读性的印象。