編碼風格：如何改進公司的編碼風格和標准

Question

提高公司編碼風格標准的最佳方法是什么？ 我們在這里以C＃為例。

我想開發人員之間需要考慮很多差異。 具體的可能是教育，經驗和過去的編程語言。

一個人如何證明某事物是正確的呢？

一個人可能會說“ 我把我的身體移到我用四輪車賺錢的地方 ”。 那么為什么說“ 我開車上班 ”更為“正確”呢？

有些人可能希望代碼更明確，代碼更多。 有些人可能會喜歡更嚴格的代碼

// Explicit
string text = defaultValue;
if (string.IsNullOrEmpty(text)) {
   text = fallbackValue;
}
// Tighter
string text = defaultValue ?? fallbackValue;

或者舊的保護性編程風格，在開始時檢查錯誤情況，而不是將整個方法體包裝在正的if子句中：

public string ChangeText(string text)
{
    if (!string.IsNullOrEmpty(text))
    {
        // Do a lot of stuff 
    }
    else {
        throw new Exception();
    }
}
// vs.
public string ChangeText(string text)
{
    if (string.IsNullOrEmpty(text)) {
        throw new Exception();
    }
    // Do a lot of stuff
}

舊的“我有閱讀此代碼的麻煩”在這里有效嗎？ 這與將Generics引入C＃的情況相同，人們在閱讀它時遇到了初步的麻煩。

某些開發人員不習慣的不可讀代碼和代碼之間的界線在哪里？

Phil Haacks“ 新語言關鍵詞悲傷的7個階段 ”的哪一部分在這里有效點？

有沒有簡單的方法來設置編碼標准並在公司中維護它們？

更新 ：考慮變量命名之類的事情，這些事情無法在文檔中真正定義。 或者可以嗎？

Answer 1

在公司設置編碼標准的最簡單方法：

創建標准文檔並加以執行。

...人們喜歡抱怨代碼質量，但很少有人會坐下來花時間創建標准文檔。 值得付出努力，只要您可以執行它（代碼審查等），那么您必然會注意到代碼的改進。

Answer 2

您總是可以使用Microsoft的StyleCop等免費工具。

您可以禁用或修改您不喜歡的規則

Answer 3

編碼風格有兩個主要方面：

1. “我在哪里放開支架？” 類型問題 - 這些通常是不重要的，即沒有真正的理由偏愛一種風格而不是另一種風格。
2. 實際的編碼規則，就像我們在函數中間使用return一樣。

就我看來，對於排名第一的問題，任何爭論都沒有意義。 只需在標准文檔中設置一個標准，並對其進行強制執行（稍后將詳細介紹）。

至於第二個問題，我老實說不確定它是否應該是規范的。 我個人喜歡使用返回值來傳遞函數以檢查錯誤情況，我知道有些人在練習時會感到畏縮。 但是在一天結束時，我們通常可以很好地閱讀彼此的代碼。 這些問題更多的是關於你喜歡表達自己，你更容易寫什么，我不希望公司制定達到這個水平的規則。

至於如何執行事情，標准文件是好的，但根據我的經驗，從來沒有閱讀或密切關注，很快就會被遺忘。 最好的方法是使用某種自動化工具，告訴您違反了標准。

例如，即使作為一個全新的Java程序員，我也知道何時大寫/小寫我的標識符，因為Eclipse讓我（悄悄地，不引人注意地）知道標准是什么。

Answer 4

首先，您將始終必須執行編碼樣式 - 永遠不會獲得同意。
那就是為什么我會嘗試自動檢查一致性。 根據您的語言，您可以使用StyleCop（用於.Net）或類似於linux下的縮進。

每個開發人員都可以在他的環境中使用自己的代碼樣式（重新格式化可以非常簡單，具體取決於您的環境），但所有簽入的代碼都必須符合公司的風格。

你選擇哪種款式？ 嗯，通常已經有流行的風格 - 取決於語言。 對於你的例子（C＃），我會選擇微軟風格。 最后：只有項目經理（高級程序員）才有權對其進行調整。

Answer 5

大多數公司使用編碼風格指南/約定。 這些文檔告訴你應該總是圍繞if主體做一個大括號，即使是一個命令，你應該用制表符/空格縮進，等等。

有很多工具可以（自動）檢查和強制執行編碼風格。 （java世界的一個例子是checkstyle，它可以集成到eclipse中，也可以集成到像'hudson'這樣的持續集成解決方案中。）

Answer 6

一個人如何證明某事物是正確的呢？

容易：只是不要。 選擇編碼風格，進行溝通並加以強制執行。

Answer 7

我認為一致性在這里很重要。 除非當前的方法特別糟糕，否則進入關於哪種方式比另一種更好的語義爭論並不是很重要。

重要的是團隊一致地編寫代碼，這樣如果有人辭職或被公共汽車擊中，那么他/她的同事就會知道代碼在被迫使用時會發生什么。