“Programs are meant to be read by humans and only incidentally( 顺便；偶然地；附带地) for computers to execute.” —Donald Knuth
When a team is brought together(被放在一起) for the first time, everyone brings with them their own ideas about how code should be written. After all, each team member comes from a different background. Some may come from one-man shops where they could do whatever they wanted; others may have been on different teams that had particular ways of doing things that they liked (or hated). Everyone has an opinion about how code should be written, and it usually falls in line with(fall in line with 同意) how that individual would personally write it. Establishing style guidelines should always come as early in the process as possible.
The terms “style guidelines” and “code conventions” are often used interchangeably. Style guidelines are a type of code convention aimed at the layout of code within a file. Code conventions can also include programming practices, file and directory layout, and commenting. This book is actually a collection and discussion of code conventions for JavaScript.
Why Style Guidelines?
Figuring out style guidelines is a process that typically takes longer than it should.Everyone has an opinion and, when you’re going to be spending eight hours a day writing code, all programmers want to do so in a way that is comfortable to them. It takes some compromise within the team and a strong leader to move the conversation forward. Once established, style guidelines allow the team to work at a much higher level, because all code looks the same.
Having all code look the same is incredibly important on a team, because it allows:
• Any developer to work on any file regardless of(不管) who wrote it. There’s no need to spend time reformatting or deciphering the logic of the file, because it looks the same as everything else. If you’ve ever opened a file and immediately fixed all the indentation before starting your work, you can understand the time savings consistency provides when working on a large project.
• Errors become more obvious. If all code looks the same, and you come across some code that doesn’t, you’ve likely found a problem.
It’s no wonder that large companies around the world have published style guidelines either internally or publicly.
Style guidelines are a personal thing and must be developed within a team to be effective. This section of the book lists recommended focus areas for the development of your JavaScript code conventions. In some cases, it’s impossible to tell you that one guideline is better than another, because some are just a matter of preference. Rather than trying to force my preferences upon you, this chapter highlights important aspects that should be covered in your style guidelines. My personal code style guidelines for JavaScript are included in Appendix A.