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.

如果您喜歡這篇文章，請反復粉碎這篇文章底部的拍手圖標，以幫助傳播這個詞。如果您想類似的內容，請在下面注冊我的每周開發精通通訊。