c++编码风格指南_100％正确编码样式指南

c++编码风格指南

Tabs or spaces? Curly brace on the same line or a new line? 80 character width or 120?

制表符或空格？在同一行或新行上大括号？ 80个字符的宽度还是120个字符？

Coders love to argue about this kind of stuff. The tabs vs. spaces debate even made it into a famous episode of the HBO show Silicon Valley.

编码人员喜欢争论这种事情。标签与空间的辩论甚至使它成为了HBO节目《 硅谷》中的著名一集。

Well in this article, I will finally give you the definitive answers you seek.

好吧，在本文中，我将最终为您提供确定的答案。

Early in my career, I engaged in all kinds of holy wars. I would read some article about why a particular convention was correct, while another was totally wrong. I would get right up there on my high and mighty horse and proclaim to anyone who would listen that they were wrong and I was right.

在我职业生涯的早期，我参加了各种圣战。我会读一些文章，说明为什么某个特定约定正确，而另一个完全错误。我会骑着高大而有力的马上去，向任何听他们说错了而我是对的人宣告。

It took me years to find the right answers but I’ve finally done it and it turns out the answer is…

我花了多年的时间才找到正确的答案，但我终于做到了，事实证明答案是…

These things don’t matter.

这些都没关系。

Consistency matters. Readability matters. Arguing and stressing about one convention over another matters not.

一致性很重要。可读性很重要。争论和强调一个公约而不是另一个公约并不重要。

Over the past 20+ years, I’ve followed every imaginable trend. I’ve followed the different conventions of different languages. None of it has impacted my bug count or made my code any more efficient.

在过去的20多年中，我一直关注着每一个可以想象的趋势。我遵循了不同语言的不同约定。这些都不会影响我的错误计数或提高我的代码效率。

Don’t get me wrong, clean-looking, well-formatted code will be easier to change and maintain over time, and that’s a good thing.

别误会，外观简洁，格式正确的代码将随着时间的推移更易于更改和维护，这是一件好事。

There’s also nothing wrong with wanting your code to look beautiful. But too often, this is used to justify what essentially boils down to procrastination.

希望代码看起来很漂亮也没有错。但是很多时候，这是用来证明本质上归结为拖延的理由。

We procrastinate like this because coding is hard. Things can get complicated in a hurry and we — especially those of us who may be new to this level of complexity — can become intimidated by this complexity and grow insecure about our ability to tame it.

我们这样拖延是因为编码很难。事情可能会急忙变得复杂，而我们-尤其是对于那些刚刚接触到这种复杂性水平的人-可能会被这种复杂性吓倒，并对我们驯服它的能力变得不安全。

It’s much safer to argue over trivial things. Our perceived incompetence is less likely to be exposed that way.

在琐碎的事情上争论要安全得多。我们认为自己的无能这样暴露的可能性较小。

The phenomena of debating trivialities to avoid hard problems is so common that there are a number of popular theories that describe it.

为了避免难题而进行琐碎辩论的现象非常普遍，以至于有许多流行的理论对此进行了描述。

One of the most popular is Parkinson’s Law of Triviality which states that members of an organization give disproportionate weight to trivial issues.

最受欢迎的方法之一是帕金森的琐碎法则，其中指出组织成员对琐碎问题的重视程度过高。

In illustrating this law, Parkinson used the fictional example of a committee whose job it was to approve plans for a new nuclear plant, but who spent the majority of their time arguing over what materials to use for the staff bike shed. They neglected the proposed design of the plant itself, which was a far more important but also far more complex issue.

在说明这项法律时，帕金森举了一个虚构的例子来说明这个委员会的工作，该委员会的工作是批准新核电站的计划，但他花了大部分时间在讨论用于员工自行车棚的材料。他们忽略了工厂本身的拟议设计，这不仅是重要的问题，而且也是更为复杂的问题。

Because of the reference to a bike shed in this canonical example, Danish developer, Poul-Henning Kamp later coined the term “bike shed effect” or simply “bike shedding” to describe it.

由于在此典型示例中提到了自行车棚，丹麦开发商Poul-Henning Kamp后来创造了术语“自行车棚效应”或简称为“自行车脱落”来描述它。

If you work in software development — and especially if you hang out with other coders on social media — you’re likely to come across some form of bike-shedding almost daily.

如果您从事软件开发工作，特别是如果您在社交媒体上与其他编码员一起闲逛，那么您几乎每天都可能会碰到某种形式的骑自行车。

If you find yourself getting into an unusually heated debate with your fellow coders, online or in-person, it’s probably also worth remembering Sayre’s Law…

如果您发现自己与在线或面对面的编码员展开了异常激烈的辩论，那么也有必要记住塞勒定律 ……

“In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

“在任何争议中，感觉的强度与所涉问题的价值成反比。”

As a consultant, I bounce from client to client, and each one has their own rules and conventions. I decided long ago that the only way for me to succeed was to let go of the trivialities and focus on the hard problems. When it comes to coding standards, I take what I get and I don’t get upset.

作为顾问，我在客户之间跳来跳去，每个人都有自己的规则和约定。我很久以前就决定，我要成功的唯一方法就是放下琐碎的事，集中精力解决棘手的问题。当涉及到编码标准时，我会接受，但不会感到沮丧。

If you happen to find yourself in a position to pick your own style guide, I recommend that you ask yourself these two simple questions:

如果您碰巧发现自己可以选择自己的风格指南，则建议您自问以下两个简单问题：

Is there tooling that will automatically apply the style rules to my code with little to no intervention from me?
是否有工具可以将样式规则自动应用于我的代码，而几乎不需要我干预？
Are the tools and underlying styles actively maintained and/or used by reputable organizations?
信誉良好的组织是否积极维护和/或使用了工具和基础样式？

If you can answer “yes” to both of those questions, then you’re good to go. Simple as that.

如果您对这两个问题都回答“是”，那么您就很好了。就那么简单。

Here are some options that fit the bill for some of today’s more popular web languages:

以下是一些适合当今一些较流行的网络语言的选项：

DotNet Code Formatter

DotNet代码格式化程序

Java: Google-Java-Format

Java：Google Java格式

Javascript Standard Style (N.B. this is a product name, not an actual, official JavaScript standard)

Javascript标准样式 (注意，这是产品名称，而不是实际的官方JavaScript标准)

PHP Coding Standards Fixer

PHP编码标准修复程序

Python: Google’s YAPF

Python：Google的YAPF

Ruby: Rubocop

Ruby：Rubocop

If you enjoyed this article, please smash the clap icon at the bottom of this post repeatedly to help spread the word. And if you want to read more stuff like this, please sign up for my weekly Dev Mastery newsletter below.

如果您喜欢这篇文章，请反复粉碎这篇文章底部的拍手图标，以帮助传播这个词。如果您想类似的内容，请在下面注册我的每周开发精通通讯。