代码是为计算机还是为人？
最终，代码（最终）编译成 CPU 的指令。 然而，（以我的拙见）代码是供人类阅读、更新和交互的。 这使我得出以下观察结果：
其他工程师无法阅读的代码，即使它具有功能，也是糟糕的代码。
考虑到这一点，程序员可以做些什么来使代码更容易被人类阅读？
命名约定？ （乔尔对此有很多话要说）
代码结构/布局？ （看在上帝的份上，请不要陷入
{放置争论）措辞？ （是否可以编写看起来更像英语的代码）
Ultimately, code compiles down (eventually) into instructions for a CPU. Code, however, (in my humble opinion) is for human beings to read, update, and interact with. This leads me to the following observation:
Code that is unreadable by other engineers, even if it's functional, is bad code.
With that in mind, what can this programmer do to make code more easily read by humans?
Naming Conventions? (Joel has a fair amount to say on that one)
Code Structure/Layout? (please, for the love of god, don't get into the
{placement debate)Phrasing? (Is it possible to write code that looks more like the English language)
Are there good articles out there beyond Joel's.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
是的。
如果计算机不运行它，它就坏了。 如果人们无法阅读它，它就会被破坏。 很快。
Yes.
If the computer doesn't run it, it's broken. If people can't read it, it will be broken. Soon.
但是既然您已经自己得出了这个结论，那么可以说这是一个很大的话题。 这不是你能够得到单一答案的事情。 让你的代码可维护不仅限于编码风格，还涉及你的整体设计以及构建过程。 以下是该网站上的一些标签，其中几乎所有问题和答案都会涉及该主题：
But since you've already reached that conclusion on your own, suffice to say that this is a huge topic. It's not something you'll be able to get a single answer on. Making your code maintainable is not limited to coding style, but also involves your overall design as well as your construction process. Here's some tags on this site where pretty much all the questions and answers will impinge on this topic:
——摘自《计算机程序的结构和解释》，作者：Abelson 和 Sussman
-- from "Structure and Interpretation of Computer Programs" by Abelson and Sussman
编译器并不关心你的代码是写得干净还是乱七八糟——只要语法正确，代码就会编译并运行。
但是，当涉及到代码维护时，清晰编写的代码对人们来说将非常有用。 从商业案例的角度来看，新程序员理解代码所需的时间越短，让新程序员跟上进度所需的资金就越少。 因此，更干净的代码更有价值。 当程序员需要花费 100% 的时间来理解不可读的代码时，执行速度要快 5%，这有什么意义呢？ 毕竟程序员的工资还是不少的。
遵循风格、变量命名等编码标准编写代码对于保持多人编写的代码一致非常重要。 遵循良好编码标准的一致代码库将更易于维护。
通常，在优化代码时，它可能会变得难以阅读，但总的来说，编译器现在在优化方面已经变得更好，因此编写更清晰的代码也将提高编译器捕获某些构造并对其执行优化的机会，从而提高性能。
为人写作，而不是为机器写作。
The compiler doesn't care whether your code is cleanly written or unreadable mess -- as long as the syntax is correct, the code will compile and it will run.
However, when it comes to maintenance of the code, cleanly written code for people is going to be very useful. From a business case standpoint, the shorter it takes to understand the code for a new programmer, the less money is required to bring the new person up to speed. Therefore, cleaner code has more worth. What's the point when unreadable code performs 5% faster when it will take 100% more time to understand by the programmer? After all, programmers cost quite a bit of money.
Writing code following coding standards for style, variable naming, and such is important in keeping the code written by multiple people to be consistent. A consistent codebase following a good coding standard is going to be more maintainable.
Often, when it comes to optimizing code, it can turn into a unreadable mess, but generally, compilers have become better these days at optimizing, so having more clearly written code will also improve the chances that the compiler will catch certain constructs and perform optimizations on it, leading to improved performance.
Write for people, not the machine.
Roedy Green 编写了一份内容广泛的指南，名为：不可维护的代码。
答案：阅读本指南并将其相反的内容应用到您的开发活动中。
一般原则部分：
虽然这是一个坚定的玩笑，但它实际上是一个非常有用的列表（除了令人讨厌的广告），如果您真正关心编写可读/可维护的代码，则应避免使用这些内容
Roedy Green wrote an extensive guide called: Unmaintainable Code.
Answer: Read this guide and apply the reverse of everything it says to your development activities.
Quote from the general principles section:
While it's a firmly tongue in cheek, it is actually a very useful list (apart from the obnoxious ads) of what to avoid if you actually care about writing readable / maintanable code.
我对此的看法有点离题——这与可读性无关，而是与可维护性有关。
阅读只是看着代码并认为你可以阅读它。 通常认为，为了可读，它必须对于那些没有付出努力去理解它的人来说是可读的。
维护是进行更改以修复错误或实现新的/更改的需求。 阅读只是这个过程的一部分。 我不知道有任何可维护的代码不需要维护者的学习曲线，并且对于没有爬过该曲线的人来说，代码看起来“不可读”。
同时，我认为教导维护人员帮助他们攀登学习曲线是程序员责任的一部分。 一种方法是留下有关如何执行未来可能发生的各种变化的分步说明。
我经常看到代码中充满了空白，因此屏幕上显示的内容较少，并且给出了冗长的命名和冗长的注释。 这给人一种可读性的印象。
My take on it is a bit tangential - it's not about readability, it's about maintainability.
Reading is just looking at the code and thinking you can read it. It is usually assumed that, to be readable, it has to be readable to someone who has put no effort into understanding it.
Maintaining is making changes to fix bugs or implement new / changed requirements. Reading is just part of that process. I don't know of any maintainable code that doesn't require a learning curve on the part of the maintainer, and to someone who has not climbed that curve the code looks "not readable".
At the same time, I think it is part of a programmer's responsibility to teach the maintainer to help them climb the learning curve. One way to do that is to leave step-by-step instruction on how to perform the kinds of future changes that could be anticipated.
I often see code that is puffed up with whitespace so less of it fits on the screen, and given verbose naming and gabby comments. This gives the impression of readability.
<讽刺>代码只需由机器读取即可。 只要最终结果满足用户的需求，代码是什么样子并不重要。现在可维护的代码或可以更改的代码，那就完全是另一回事了。
你会在餐巾纸背面写下计划来建造一座房子，还是在建造完一座房子后扔掉蓝图，有一天你可能想增加一个房间？
<sarcasm>Code only has to be read by a machine. So long as the end result fulfulls the user's need, it doesn't matter what the code looks like.</sarcasm>Now maintainable code or code that can change, that's a completely different story.
Would you build a house with a plan scribbled on the back of a napkin, or throw away the blueprints after you're done building a house you might want to add a room onto one day?
不要在类型安全语言中使用匈牙利表示法。
Don't use hungarian notation in a typesafe language.
我对此的看法是一切都是相对的。
当您需要更改代码时，代码是为您准备的，而执行代码时则是为机器准备的。
如果代码有效，那么它就有可能被读取。
你身上的人性和合作性应该使其易于被其他人阅读，但最终，除了约定之外，代码的可读性有时可能取决于旁观者的眼睛。
代码越容易被人们阅读，就越容易更改和维护，因为进化受益于您应用于问题的贡献/贡献者的数量，因此可以比不可读的代码更好地声明这种类型的代码。
但最终，代码将被制作成机器的一组指令。
人类的意图转化为机器可以遵循的东西，因此代码同时适用于两者，一次一个。
my take on this is that everything is relative.
When you need to change code, the code is for you, when its executed its for the machine.
If a code is functional it has the potential of being read.
The human and cooperative being in you should make it easily readable to other humans, but ultimately, conventions aside, the readability of code might sometimes be in the eye of the beholder.
The easier the code is to be read by people, the easier it can be changed and maintained, since evolution benefits from the number of contributions/contributors you apply to a problem, this type of code can be declared better than unreadable code.
But ultimately, the code is to be made into a set of instructions to the machine.
Human intentions translated into something the machine can follow, so the code is for both , one at a time.
缺少项目：评论。
即使代码对其作者来说完全可读，但它可能并不适合所有人。
Missing item: comments.
Even if the code is perfectly legible to its author, it might not be for everyone.