13代码布局很重要

An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a reason to change the code, because someone once broke something by letting a line slip into one of the special columns at the beginning of a line. This applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag.

N年前，我在编写一个Cobol系统。在编写这个系统时，除非必须更改代码，否则程序员是不可以改变缩进的。因为曾经有人让一条线滑入了一行的开头的一个特殊的列，导致出了一些问题。即使是代码布局有误的时候，也是不能随便调整缩进的。所以我们必须非常仔细地阅读代码，因为我们不能相信代码。这项政策程由于拖累了程序员，一定花了一大笔钱。

There's research to show the we all spend much more of our programming time navigating and reading code — finding where to make the change — than actually typing, so that's what we want to optimize for.

有研究显示，程序员会将更多的编程时间花在导航和读取代码上 --- 寻找在哪里做出改变 --- 而不是花在敲键盘上，所以这是我们想要优化的。

Easy to scan. People are really good at visual pattern matching (a leftover from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the "accidental complexity" that comes with most commercial languages, fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That's why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods.
易于浏览。 人们非常擅长视觉模式匹配(这是我们祖先在大草原上找狮子时留下的一点点痕迹)，所以我可以自己动手，让所有与领域无关的东西（大多数商业语言附带的所有“意外复杂性”），通过标准化而消失在背景中。如果行为相同的代码看起来相同，那么我的感知系统将帮助我找出差异。这就是为什么我遵守关于如何在编译单元中布局类的各个部分的约定：常量、字段、公共方法、私有方法。
Expressive layout. We've all learned to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than just listing the steps — right? The code's layout is part of this expressiveness too. A first cut is to have the team agree on an automatic formatter for the basics, then I might make adjustments by hand while I'm coding. Unless there's active dissension, a team will quickly converge on a common "hand-finished" style. A formatter cannot understand my intentions (I should know, I once wrote one), and it's more important to me that the line breaks and groupings reflect the intention of the code, not just the syntax of the language. (Kevin McGuire freed me from my bondage to automatic code formatters.)
表达性布局。 我们都学会了花时间找到正确的名称，以便我们的代码尽可能清楚地表达它所做的事情，而不仅仅是列出步骤 --- 对吧？代码的布局也是这种表现力的一部分。首先，让团队选择一个基本的自动格式化程序，然后在编码时可以做手工调整。除非有较大的意见分歧，否则一个团队很快就会形成一种共同的“手工完成”风格。格式化程序无法理解我的意图(我应该知道，我曾经写过一个)，更重要的是，换行和分组反映了代码的意图，而不仅仅是语言的语法。（Kevin McGuire让我摆脱了对自动代码格式化器的束缚。）
Compact format. The more I can get on a screen, the more I can see without breaking context by scrolling or switching files, which means I can keep less state in my head. Long procedure comments and lots of whitespace made sense for 8-character names and line printers, but now I live in an IDE that does syntax coloring and cross linking. Pixels are my limiting factor so I want every one to contribute towards my understanding of the code. I want the layout to help me understand the code, but no more than that.
压缩格式。 我能在屏幕上看到的越多，滚动或切换文件就能看到的越多，而且不会破坏上下文，这意味着我只需要记忆较少的上下文内容。长程序注释和大量空白对于8个字符的名字和行式打印机来说是有意义的，但是现在我们在使用IDE，它可以进行语法着色和交叉链接。像素是我的限制因素，所以我希望每个人都有助于我对代码的理解。我希望布局能帮助我理解代码，但不要超过这个范围。

A non-programmer friend once remarked that code looks like poetry. I get that feeling from really good code, that everything in the text has a purpose and that it's there to help me understand the idea. Unfortunately, writing code doesn't have the same romantic image as writing poetry.

一位非程序员朋友曾说，代码看起来像诗。我从非常好的代码中得到这种感觉，文本中的每一件东西都有其目的，并可以帮助我理解这个想法。不幸的是，写代码并不像写诗那样浪漫。

Previous12编码即设计 Next14代码审查

Last updated 6 years ago

有研究显示，程序员会将更多的编程时间花在导航和读取代码上 --- 寻找在哪里做出改变 --- 而不是花在敲键盘上，所以这是我们想要优化的。

Easy to scan. People are really good at visual pattern matching (a leftover from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the "accidental complexity" that comes with most commercial languages, fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That's why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods.
易于浏览。 人们非常擅长视觉模式匹配(这是我们祖先在大草原上找狮子时留下的一点点痕迹)，所以我可以自己动手，让所有与领域无关的东西（大多数商业语言附带的所有“意外复杂性”），通过标准化而消失在背景中。如果行为相同的代码看起来相同，那么我的感知系统将帮助我找出差异。这就是为什么我遵守关于如何在编译单元中布局类的各个部分的约定：常量、字段、公共方法、私有方法。
Expressive layout. We've all learned to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than just listing the steps — right? The code's layout is part of this expressiveness too. A first cut is to have the team agree on an automatic formatter for the basics, then I might make adjustments by hand while I'm coding. Unless there's active dissension, a team will quickly converge on a common "hand-finished" style. A formatter cannot understand my intentions (I should know, I once wrote one), and it's more important to me that the line breaks and groupings reflect the intention of the code, not just the syntax of the language. (Kevin McGuire freed me from my bondage to automatic code formatters.)
表达性布局。 我们都学会了花时间找到正确的名称，以便我们的代码尽可能清楚地表达它所做的事情，而不仅仅是列出步骤 --- 对吧？代码的布局也是这种表现力的一部分。首先，让团队选择一个基本的自动格式化程序，然后在编码时可以做手工调整。除非有较大的意见分歧，否则一个团队很快就会形成一种共同的“手工完成”风格。格式化程序无法理解我的意图(我应该知道，我曾经写过一个)，更重要的是，换行和分组反映了代码的意图，而不仅仅是语言的语法。（Kevin McGuire让我摆脱了对自动代码格式化器的束缚。）
Compact format. The more I can get on a screen, the more I can see without breaking context by scrolling or switching files, which means I can keep less state in my head. Long procedure comments and lots of whitespace made sense for 8-character names and line printers, but now I live in an IDE that does syntax coloring and cross linking. Pixels are my limiting factor so I want every one to contribute towards my understanding of the code. I want the layout to help me understand the code, but no more than that.
压缩格式。 我能在屏幕上看到的越多，滚动或切换文件就能看到的越多，而且不会破坏上下文，这意味着我只需要记忆较少的上下文内容。长程序注释和大量空白对于8个字符的名字和行式打印机来说是有意义的，但是现在我们在使用IDE，它可以进行语法着色和交叉链接。像素是我的限制因素，所以我希望每个人都有助于我对代码的理解。我希望布局能帮助我理解代码，但不要超过这个范围。