2008-11-12 87 views
21

幾年前,當我開始一個小型開發項目時,其他開發人員和我坐下來商定一個妥協大括號和縮進樣式。這不是任何人的最愛,但這是沒有人真正討厭的。我寫了一個.indentrc配置文件到這個樣式中,並且有一個簽入觸發器,它會在每個文件簽入時對其進行縮進。這使得它不會影響你編寫代碼的風格,它會在別人看到它之前成爲團體標準。這具有一致性的優點。但是我從來沒有見過其他人在此之前或之後這樣做過。強制編碼風格

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

+0

+1:好主意 - 下面列出的一些增強功能也可能是積極的補充。 – 2008-11-12 15:35:22

+1

現代的IDE使這種宗教的東西沒有意義。兩個按鍵和文件看起來像開發人員想要的方式。誰在乎它在源代碼控制中的樣子。當然,這使得發現編輯是一個痛苦的屁股。 – 2009-01-12 01:15:24

+1

@ RobertC.Barth:爲什麼不使用rsync作爲您的VCS?有所有不錯的功能:分散,ssh,壓縮。天哪,誰需要差異,責備和三路合併? – 2011-12-16 13:48:04

回答

11

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

使用check-鉤:

臨:但是允許他們希望程序員來寫,這樣他們就不會去想標準或改變他們編寫代碼的方式。這可以最大限度地降低對策略的抵制力,並且在編寫代碼時不會對其生產力產生負面影響。

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

往前一步,在開發過程中使用的中性風格:

臨:鼓勵在中性風格流暢,前後它已選中每個人都可以閱讀其他人的代碼

騙局:你會遇到更多的阻礙你的開發者這樣做。根據你的文化,這可能比它的價值更麻煩。

4

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

+0

「CVS(通用術語)」 - > VCS/SCM? – hangy 2008-11-12 15:37:12

+0

代碼版本系統,但沒有任何特定的。 – Elie 2008-11-12 16:00:06

15

我會說好主意。我會更進一步,讓每個人都在他們的IDE中使用配置文件,以便他們默認以默認的風格編寫。如果他們必須以中性風格來看待其他人的代碼,他們可能會習慣它。即使他們自己的代碼在一次辦理登機手續後應該處於中立風格,那麼爲什麼要以他們自己的個人風格開發新代碼呢?

7

如果您將其限制爲對大括號和縮進執行樣式,那麼我認爲這是個好主意。但是,如果您嘗試執行每一種格式標準,那麼它可能不會。在我看來,有時候打破標準是有道理的。舉例來說,我更喜歡

int x = y * z; 

int x = y*z; 

,因爲它更易於閱讀。不過,我更喜歡大大

int a = b*c + d*e; 

int a = b * c + d * e; 

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

所以你的強制縮進和大括號的政策聽起來很不錯。但如果有人試圖盲目執行其他間距規則,我認爲它不會奏效。

+1

只要每個人都同意一個可接受的標準,我不明白爲什麼這不能包括括號和縮進。 – 2008-11-12 15:32:50

2

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

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

2

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

例如,如果您的代碼中有很多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執行。工作得很好。

0

我相信你現在決定了你的開發環境。如果您使用Eclipse,則可以在Java編輯器上啓用格式化源保存操作,該操作會在每次保存時重新格式化。這樣做的主要好處是,源代碼倉庫在源代碼倉庫完成時標記源代碼的機會,而不是源代碼稍後重新格式化。

使其成爲自動步驟。稍後你會很感激。

2

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

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

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