標準文件

Question

我正在爲約15名開發人員編寫一個編碼標準文檔，每年的項目負載爲10至15個項目。在其他章節中（我可能會在這裏發帖），我正在編寫一段代碼格式。所以，首先，我認爲明智的是，無論出於何種原因，我們都建立了一些基本的，一致的代碼格式/命名標準。

我已經看過過去3年中寫過的大約10個項目，顯然我找到了很多風格。承包商有時進出，有時甚至是團隊規模的兩倍。

我正在尋找一些代碼格式化和命名標準的建議，這些建議確實得到了回報......但這也確實是有道理的。我認爲一致性和共享模式可以大大提高代碼的可維護性......但是，在定義所述標準時，我還應該考慮其他事情嗎？

• 你如何排列括號？在處理類，方法，嘗試catch塊，switch語句，if else塊等時，你遵循相同的括號指導原則嗎？

• 你是否在列上排列字段？你是否用下劃線註釋/前綴私有變量？你是否遵循任何命名規則，以便更容易地找到文件中的詳細信息？你如何訂購你的班級成員？

那麼對名稱空間，包裝或源代碼文件夾/組織標準的建議呢？我傾向於開始是這樣的：

<com|org|...>.<company>.<app>.<layer>.<function>.ClassName 

我很好奇，看看是否有其他的，比較公認的，實踐比我習慣了 - 之前我冒險離開支配這些標準。已經在線發佈的標準的鏈接也會很好 - 即使我已經做了一些。

Answer 1

首先找到一個適用於您的語言的自動代碼格式化程序。原因：無論文件如何，人們都會不可避免地違反規則。通過格式化程序運行代碼要比在代碼審查中挑選代碼要容易得多。

如果您使用的是具有現有標準（例如Java，C＃）的語言，那麼最簡單的方法就是使用它，或者至少從第一份草稿開始。 Sun在格式化規則中考慮了很多，你不妨利用它。

無論如何，請記住，許多研究表明，支撐位置和空白使用等不同的事物對生產力或可理解性或流行性缺陷沒有可衡量的影響。只要有任何標準是關鍵。

Answer 2

這顯然取決於語言和技術。通過你的示例名字空間的外觀，我將猜測java，在這種情況下，http://java.sun.com/docs/codeconv/是一個非常好的開始。你可能也想看看maven的標準目錄結構，這將使你的所有項目看起來很相似。

Answer 3

我要第二個傑森的建議。

我剛剛完成了一個主要用於perl的10-12團隊的標準文檔。該文件表示使用「類似於複雜數據結構的類似於縮進的縮進」。我們還向每個人提供了可以清理他們的代碼以滿足此標準的示例perltidy設置。這個語言非常清晰並且非常符合行業標準，所以我們在團隊中有很大的收穫。

在着手撰寫本文檔時，我問了一些有關我們倉庫中優秀代碼的示例，並搜索了一些其他標準文檔，這些文檔比我更聰明，以構建模板。這是艱難的簡潔和務實，沒有跨越微管理區域，但非常值得;有任何標準確實是關鍵。

希望它能解決問題！

Answer 4

從汽車行業的到來，這裏是用於具體原因幾個風格標準：

控制結構始終使用大括號，然後把它們放在單獨的行。這消除了人們添加代碼並將其包括在內的問題，或者將其錯誤地包含在控制結構中。

if(...) 
{ 

} 

所有開關/選擇都有一個默認情況。如果不是有效路徑，則默認情況下會記錄錯誤。

出於與上述相同的原因，任何if ... elseif ...控制結構必須以其他默認值結束，如果它不是有效路徑，也會記錄錯誤。單個if語句不需要這個。

在環形或控制結構有意爲空的偶然情況下，總是放置一個分號以表示這是有意的。

while(stillwaiting()) 
{ 
    ; 
} 

命名標準對typedef，定義的常量，模塊全局變量等有很不同的樣式。變量名包括類型。你可以看看這個名字，並且瞭解它的屬性，範圍和類型。這使得它很容易檢測到類型相關的錯誤等。

還有其他的，但這些都是我的頭上。

-Adam