您認爲軟件公司應該向開發人員強加一種編碼風格嗎？

Question

如果您認爲不應該，請解釋原因。

如果是，您認爲指南應該有多深？例如，應該包含代碼縮進？

Answer 1

我覺得團隊（而非公司）需要對合理的一貫作風一套指導方針達成一致。它使維護更直接。

有多深？儘可能淺，你可以同意。越短越清晰，所有團隊成員都可以同意並願意遵守。

Answer 2

我相信擁有一致的代碼庫很重要。它增加了我們的代碼的可維護性。如果每個人都希望有相同類型的代碼，他們可以輕鬆閱讀和理解它。

除了今天的IDE和它們的自動生成功能以外，它並沒有太大的麻煩。

P.S： 我有這種討厭的習慣，把我的牙套放在下一行:)。沒有人似乎喜歡它

Answer 3

在我看來，我認爲這是非常必要的標準和風格指南。因爲當你的代碼庫增長時，你會希望它保持一致。

作爲一個方面說明，這就是爲什麼我喜歡Python;因爲它已經在如何構建應用程序等方面制定了相當多的規則。將它與Perl，Ruby或任何你有極大自由的地方（在這種情況下並不是那麼好）進行比較。

Answer 4

我認爲程序員應該能夠適應其他程序員的風格。如果一個新的程序員不能適應，那通常意味着新的程序員太固執，不能使用公司的風格。如果我們都可以做我們自己的事情，這將是很好的;但是，如果我們都遵循一些韌體指導原則進行編碼，它將使調試和維護更加容易。如果標準經過深思熟慮而不是太嚴格，這纔是真實的。

While I don't agree with everything, this book contains an excellent starting point for standards

Answer 5

是的，但在合理範圍內。

所有現代化的IDE都提供了一鍵式打印代碼，所以在我看來，「縮進」點是非常不相關的。

更重要的是要建立最佳實踐：例如，儘可能少使用「out」或「ref」參數......在此示例中，您有兩個優點：提高可讀性並修復大量錯誤（很多out參數是代碼味道，應該可能被重構）。

超出我的意見是，有點「肛門」和不必要的煩人的開發。

---

好一點的哈米什·史密斯：

風格是最好的 的做法完全不同。 「編碼 標準」傾向於將兩個 放在一起，這真是令人遺憾。如果人們可以將 款式部分降到最低，並且 專注於最佳做法，那麼 可能會增加更多價值。

Answer 6

您希望每個人都以標準方式讀寫代碼。有兩種方法可以實現這一點：

1. 克隆一個開發人員幾次，並確保他們都通過相同的培訓。希望他們都應該能夠編寫相同的代碼庫。
2. 爲您的現有開發人員提供有關您所需內容的明確說明。縮進的製表符或空格。大括號坐在哪裏。如何評論。版本控制提交準則。

您離開未定義的越多，其中一個開發人員在風格上發生衝突的可能性越高。

Answer 7

該公司應該強加一些風格應該遵循。該指南的風格和程度應該由公司的開發者社區共同決定。

我肯定會制定大括號，縮進，命名等指南...... 您爲可讀性和可維護性編寫代碼。總是假定別人會讀你的代碼。 有一些工具可以自動地將代碼格式化，並且您可以強制每個人都使用該工具。

如果您對淨看看了StyleCop，FxCop的和ReSharper的

Answer 8

是的，我認爲企業應該。開發人員可能需要習慣編碼風格，但在我看來，優秀的程序員應該能夠使用任何編碼風格。正如Midhat所說：擁有一致的代碼庫非常重要。

我認爲這對開源項目也很重要，沒有主管告訴你如何編寫代碼，但許多語言都有關於代碼命名和組織方式的規範。將開源組件集成到項目中時，這會有很大幫助。

Answer 9

當然，指導方針很好，除非它是匈牙利符號（ha！），否則它可能會提高一致性並使其他人的代碼更容易閱讀。這些指導方針應該只是指導方針，而不是對程序員強制執行。你可以告訴我在哪裏把我的括號或不使用像臨時的名字，但你不能做的是逼我周圍有數組括號索引值空間（他們試了一次...）

Answer 10

有這些標準有很多很好的理由來定義應用程序的開發方式和代碼的外​​觀。例如，當每個人使用相同的標準時，自動樣式檢查器可以用作項目CI的一部分。 使用相同的標準可以提高代碼的可讀性，並有助於減少團隊成員之間以不同方式重新分解相同代碼的緊張程度。 因此：

• 由特定團隊開發的所有代碼都應遵循完全相同的標準。
• 爲特定項目開發的所有代碼都應遵循完全相同的標準。
• 最好是屬於同一家公司的團隊使用相同的標準。

在外包公司中，如果客戶想要強制執行自己的標準，可以爲一個爲客戶工作的團隊制定例外規定。在這種情況下，球隊採用客戶的標準可能是由他們公司所使用的不兼容。

Answer 11

是。

編碼標準是保證一定組織內的代碼將遵循最驚喜的原則一種常見的方式：在標準的變量命名到縮進花括號使用起始稠度。

編碼人員有自己的風格和自己的標準只會產生一個代碼庫是不一致的，混亂的，和令人沮喪的閱讀，尤其是在大型項目。

Answer 12

These是我曾經工作的公司的編碼標準。他們明確界定，並同時通過我花了一段時間來習慣他們的說話，這意味着該代碼是可讀我們所有人，並統一所有的方式。

我認爲編碼標準是很重要的一個公司內部，如果沒有設置，也將是開發商的問題之間的衝突，並與可讀性。

使代碼統一一直給最終用戶提供更好的代碼（所以看起來好像它是由一個人編寫的 - 從最終用戶的角度來看，它應該 - 該人是「公司」，它也有助於與球隊內可讀性...

Answer 13

一個共同的編碼風格促進一致性，很容易讓不同的人很容易理解，維護和擴展整個代碼庫，不僅使自己的作品。它也使得它更容易讓新人們學習的代碼更快。因此，任何一支球隊應該有代碼是如何有望被寫入。

重要準則包括指引（沒有特別的順序）：

• 空格和縮進
• 標準註釋 - 文件，類或方法頭
• 命名約定 - 類，接口，變量的命名空間，文件
• 代碼註釋
• 項目組織 - 文件夾結構，二進制文件
• 標準庫 - 要使用哪些模板，仿製藥，容器等
• 錯誤處理荷蘭國際集團 - 例外，HRESULTS，錯誤代碼
• 線程和同步

此外，警惕不能或不願適應球隊的風格，無論他們如何明亮的是程序員。如果他們不通過的隊規一玩，他們很可能不會被其他隊規如玩。

Answer 14

你認爲一個軟件公司應該強加開發商編碼風格？

不在一個頂向下的方式。軟件公司的開發人員應該就共同的編碼風格達成一致。

如果是的話，您認爲指南應該有多深？

他們只應該描述與衆所周知的慣例的差異，試圖保持偏差最小。對於像Python或Java這樣的語言來說這很容易，對於C/C++來說有點模糊，而對於Perl和Ruby來說幾乎是不可能的。

例如，應該包含代碼縮進？

是的，它使代碼更具可讀性。根據空格與製表符和（如果選擇空格）空格字符數保持縮進一致。另外，就長線達成協議（例如76個字符或120個字符）。

Answer 15

我同意一致性是關鍵。你不能依靠IDE漂亮打印來節省一天的時間，因爲你的一些開發人員可能不喜歡使用IDE，並且當你通過成千上萬的源代碼文件的代碼庫進行拖拽時，它不可行打印所有文件，然後執行回滾操作，以便您的VCS不會嘗試回退所有更改（以不必要的更新阻塞存儲庫，從而減輕所有人的負擔）。

我至少會建議規範如下（按照重要性遞減的順序排列）：

• 空白
（如果你選擇符合某些共享工具的自動漂亮的打印樣式最簡單的方法）
• 命名（文件和文件夾，類，函數，變量，...）
• 註釋（使用格式，允許自動生成文檔）

Answer 16

在b est解決方案將用於IDE將這種格式視爲元數據。例如，開放的大括號位置（當前行或下一行），操作符周圍的縮進和空白區域應該是可配置的，而無需更改源文件。

Answer 17

我的看法：

• 一些基本的規則是好事，因爲它可以幫助大家，因爲它停止開發與佈局代碼
的更清晰的方式創新，以閱讀和維護的代碼
• 太多的規矩是壞
• 個人風格​​可用於確定代碼文件的歷史記錄。可以使用Diff/Blame工具，但提示仍然有用

Answer 18

現代IDE允許您定義格式化模板。如果有公司標準，那麼開發一個配置文件來定義你關心的所有格式化值，並確保每個人在簽入他們的代碼之前運行格式化程序。如果你想對它更加嚴格，你可以爲你的版本控制系統添加一個提交鉤子，以便在代碼被接受之前縮進。

Answer 19

是使用通用命名標準以及文件後面的類和代碼的常見佈局。其他一切都是開放的。

Answer 20

每個公司都應該。一致的編碼風格確保整個團隊的代碼庫具有更高的可讀性和可維護性。

我工作的店鋪沒有統一的編碼標準，我可以說我們（作爲一個團隊）受到的影響非常大。當個人沒有意願時（比如在我的一些同事的情況下），團隊領導者不得不擺脫桌面上的拳頭，並施加某種形式的標準化編碼準則。

Answer 21

Ever語言具有社區使用的一般標準。你應該儘可能地遵循這些規則，以便你的代碼可以被習慣於該語言的其他人維護，但是不需要獨裁。

創建官方標準是錯誤的，因爲公司編碼標準通常太僵硬，無法與普通社區一起使用該語言。

如果您遇到團隊成員問題，確實在編碼風格上存在問題，那麼對於團隊來說，輕輕提示在代碼審查中並不是一個好主意。

Answer 22

編碼標準：是。由於此線程已經涵蓋的原因。

造型標準：NO。你的可讀性，是我令人迷惑的垃圾，反之亦然。良好的評論和代碼因子有很大的好處。還有gnu縮進。

Answer 23

我喜歡伊利亞的答案，因爲它包含了可讀性的重要性，並將持續集成作爲強制機制。 Hibri提到了FxCop，我認爲它在構建過程中作爲確定構建是否通過的標準之一的使用將比僅記錄標準更加靈活和有效。

Answer 24

我完全同意應該使用編碼標準，而且應該幾乎總是在團隊層面。但是有一些例外。

如果團隊正在編寫其他團隊使用的代碼（這裏我的意思是其他團隊必須查看源代碼，而不僅僅是將其用作庫），那麼制定通用標準會帶來好處跨所有使用它的團隊。同樣，如果公司的政策是頻繁地將程序員從一個團隊轉移到另一個團隊，或者處於一個團隊經常要重複使用來自另一個團隊的代碼的職位，那麼最好在整個公司強制實施標準。

Answer 25

與其他人一樣，我認爲這需要通過工程或團隊 - 公司（即業務部門）不應參與這種決策。

但是我會添加的另一件事是任何實施的規則都應該由工具強制執行，並且而不是由執行。最糟糕的情況是IMO，它是一些過分狂熱的語法優勢（是的，我們存在;我知道是因爲我們可以聞到我們自己）編寫一些文檔，列出了一套絕對沒有人真正閱讀或遵循的編碼指南。隨着時間的推移，它們會變得過時，隨着新人加入團隊並且老人離開，他們只會變得陳舊。

然後，出現了一些衝突，有人被置於不必要面對別人編碼風格的不舒服的位置 - 這種對抗應該由工具而不是人來完成。簡而言之，在我看來，這種強制執行方法是最不可取的，因爲它很容易被忽視，並且簡單地要求程序員爭辯愚蠢的事情。

一個更好的選擇（再一次，IMO）是在編譯時（或類似的）發出警告，只要你的構建環境支持這個。在VS.NET中配置它並不難，但我不瞭解其他具有相似功能的開發環境。

Answer 26

風格指南非常重要，不管它們是用於設計還是開發，因爲它們加速了協作工作人員的溝通和表現（甚至單獨按順序收集舊項目）。 不是在公司內部有一個慣例制度，只是要求人們儘可能沒有生產力。大多數項目都需要協作，甚至那些不需要我們自然願望的人也可以參與編程並保持最新狀態。我們的學習慾望阻礙了我們的一致性 - 這本身就是一件好事，但可能會讓新員工瘋狂地嘗試學習他們正在學習的系統。

就像任何其他系統的意思是好的而不是邪惡的，指南的真正力量在於其人民的手中。開發者自己將決定什麼是必要的和有用的部分，然後，希望使用它們。

就像法律。或英語。

風格指南應該儘可能深入 - 如果它出現在頭腦風暴會議中，應該包括它。你如何評論這個問題很奇怪，因爲在這一天結束時，沒有辦法「強加」風格指南，因爲它只是一個指南。

RTFM，然後收集好的東西，並繼續與它。

Answer 27

我不相信一個開發團隊應該有他們必須遵循的風格指南作爲一般規則。有例外情況，例如the use of <> vs. "" in #include statements，但這些例外應該來自必要。

我聽到人們用來解釋爲什麼樣式指導是必要的最常見的原因是用通用樣式編寫的代碼更易於維護以單獨樣式編寫的代碼。我不同意。一個專業的程序員是不會當他們看到這越陷越深：

for(int n = 0; n < 42; ++42) { 
// blah 
} 

...當他們看慣了這一點：

for(int n = 0; n < 42; ++42) 
{ 
// blah 
} 

而且，我發現它實際上是更容易如果你能通過簡單地識別他們的風格來識別編寫原始代碼的程序員，在某些情況下維護代碼。去問問他們爲什麼在10分鐘內以這樣一種令人費解的方式實施了這個小發明，而不是花一天的好時間去弄清楚他們爲什麼會做出意想不到的技術原因。誠然，程序員應該評論代碼來解釋他們的推理，但在現實世界中，程序員通常不會。

最後，如果需要喬10分鐘退格&移動他的大括號，以便比爾可以花費3秒鐘的時間查看代碼，是否真的可以節省時間讓比爾做一些不自然的事情？

Answer 28

約定有兩種類型。

A類約定：「請做這些，最好是」

和B類：「請在路的右手邊開車」，而它是好的帶動另一側，如只要每個人都以同樣的方式行事。

有沒有這樣的事情作爲一個單獨的團隊。某個好公司的所有代碼都以某種方式連接起來，風格應該一致。 讓自己習慣於一種新風格比二十種不同風格更容易。

此外，新開發者應該能夠尊重現有代碼庫的做法並遵循它們。