coding-style - enum - google c++ coding style中文



強化編碼風格 (6)

如果你把它限制在大括號和縮進上,那麼我認為這是一個好主意。 但是,如果你試圖強制每一個格式標準,那麼它可能不會。 在我看來,有時候打破標準是有道理的。 比如,我比較喜歡

int x = y * z;

int x = y*z;

因為它更容易閱讀。 不過,我非常喜歡

int a = b*c + d*e;

int a = b * c + d * e;

因為間距代表操作的順序。

所以你的執行縮進和大括號的政策聽起來非常好。 但是,如果有人試圖盲目執行其他間隔規則,我認為這不會奏效。

幾年前,當我開始一個小型的開發項目時,其他開發者和我坐下來,同意了一個妥協的大括號和縮進風格。 這不是任何人最喜歡的,但這是沒有人真正討厭的東西。 我寫了一個.indentrc配置文件到這個樣式,並且有一個check-in觸發器,當它被簽入時,它會在每個文件上運行縮進。這使得你編寫代碼的風格無關緊要,在別人看到之前,它最終會成為集體的標準。 這具有一致性的優點。 但是我從來沒有見過其他人在這之前或之後這樣做過。

那你怎麼說呢? 好主意,還是可憎?


我們使用TFS和簽入策略來運行一組Stylecop規則。 如果你的代碼沒有通過,你不能檢查它。確實工作得很好。 除了始終如一的風格和良好的評論外,它似乎還提高了代碼的總體質量 - 也許是因為開發人員被迫描述了每個方法,事件等是否被迫在檢查之前更多地考慮代碼在。

只有一個MS解決方案,但如果它是可用的,值得。


這聽起來像一個好主意。 只要你最終的風格不是什麼奇怪的東西,這是確保你的開發者使用風格的好方法。 而且它還有另外一個好處,就是他們不必這樣編寫代碼 - 當他們檢查他們的變化時,他們將被重新格式化。 如果有可用的工具,可以插入CVS(通用術語),那就太好了。


使用自動代碼格式化程序的最大問題是代碼格式化程序無法處理所有情況。

例如,如果您的代碼中有很多SQL,則可能會自動格式化SQL。 但是,如果你的SQL超過一行(多長時間?),那麼你必須格式化它。 到目前為止,我還沒有看到一個好的格式化程序,而不是正確處理這個問題。

例:

String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = 'N'";

VS

String sql = 
  "SELECT * " +
  "FROM USERS " + 
  "WHERE ID = ? " + 
  "  AND NAME = ? " +
  "  AND IS_DELETED = 'N'";

當你有很長的查詢時,第二種格式更具可讀性。 大多數格式化器會將其格式化為一行,直到行長為止。

但是,如果你正在做的是轉向

if(x=1) print("blah"); else print("eep!");

if (x = 1) {
  print("blah");
} else {
  print("eep!");
}

那麼格式化程序就可以了。 我們在工作上做了類似的事情; 它不是由CVS工具強制執行,而是由IDE執行。 工作相當好。


有一個名為EditorConfig的項目可以稍微解決這個問題。 但是,它目前只能解決縮進問題。

EditorConfig包含許多不同編輯器的插件和一個文件格式標準。 通過在你的項目的根目錄下創建一個.editorconfig文件,並安裝相應的插件,編輯器將在輸入代碼時對其進行格式化。

這是一個通用的方法(不像indentrc ,不限於C / C ++),但是你仍然可以看看這個解決方案。


採用中性編碼風格絕對是一個好主意。 但是,只有在簽入源代碼時才強制執行編碼風格可能不是一個好主意(另請參閱下面的BillElie的答案)。

使用簽入掛鉤:

Pro:允許編碼人員編寫他們希望的編碼,所以他們不必考慮標准或改變編寫代碼的方式。 這樣可以最大限度地減少對策略的抵制,而且在編寫代碼時不會對生產率產生負面影響。

Con:你的編碼人員可能對中性風格只有一個熟悉的習慣,所以你沒有得到所有使用“相同”風格的人的全部好處。 如果你的程序員必須在一對編程設置中一起工作,他們仍然會在屏幕上受到彼此的編程風格,這將與他們自己的風格或中性風格不同。

更進一步,在開發過程中使用中性風格:

專業版:鼓勵中性風格的流暢,每個人都可以在檢入之前和之後閱讀其他人的代碼。

Con:這樣做會讓你的開發人員遇到更多的阻力。 根據你的文化,這可能比它的價值更麻煩。





coding-style