2011-07-29 22 views
24

我們的開發人員之一決定向其他開發人員指定人們應如何格式化其源代碼。只希望看到Allman樣式的代碼並保存K&R樣式代碼

我自己,我堅信,奧爾曼風格縮進好於K & R.

格式樣式是像宗教一樣,總有那些不同意。無論有多少證據顯示​​一方比另一方好,人們都不會接受。

所以我想要做的是,每次我在Eclipse中打開一個文件時,我都會格式化源代碼,以便我可以查看漂亮的代碼。 每次保存時,它應該格式化爲辦公室口述的風格。

我想我可以手動做這個,並有兩個熱鍵。 CTRL-ALT-PgUp鍵:我的方式 CTRL-ALT-PgDown鍵:高速路

熱鍵選項可能是一件好事,因爲當時我去驗證一切都很好,而不是它無形地發生在幕後的。

Eclipse具有單一格式選項。我需要的是兩種格式化樣式,並將它們分別映射到快捷鍵。這是可能的,如果是的話,如何?

+3

我不知道這是否更好地通過您的版本控制系統掛鉤完成。根據您希望的方式設置Eclipse,然後強制您的VCS按照團隊需要的方式提交代碼。你使用的是什麼VCS? – MatrixFrog

+0

+1爲實用性。能夠實際安撫每一個人的好方法,而沒有你通常會遇到的所有問題。 –

+0

如果您在Eclipse中都設置了自己的格式樣式,爲什麼它在存儲庫中看起來像什麼?每個加載它的人都會自動以代碼看起來很好。 – James

回答

7

那麼,這似乎是古老的辯論又回來了。不幸的是,Eclipse JDT UI不支持應用不同的代碼格式化器。

bug no 45423,這是爲了解決這個問題。只要該錯誤仍未解決,最好的解決方法就是在提交鉤子中應用格式化程序,因爲每個項目都與自己的格式化程序相關聯;你甚至不能選擇不同的格式化程序來應用文件保存操作(首選項 - > Java - >編輯器 - >保存操作)。老實說,我不認爲快捷鍵會起作用。

另外,可能值得研究使用Questoid Code Formatter,這似乎是最接近(或唯一)的插件來支持您的需求。我沒有嘗試過使用它;我只閱讀Eclipse Marketplace的描述。

5

我的建議:只學會忍受醜陋。除非你的「與SCM中的歷史比較」功能非常好,否則格式化時容易產生虛假差異。

+4

因此,這些年來我所寫的所有格式良好的易於閱讀的熟悉的代碼都會被拋棄,轉而使用代碼blobs的醜陋柔軟粘性粘性粘液,而且我必須坐在那裏觀察它發生的事情? – Mike

+2

嗯,我想我會在這麼多的項目中走動,事實上公司,每個都有自己的風格,我沒有什麼選擇,只能堅持現在的房子風格。所以我已經習慣了這樣的事情。不得不承認,我認爲這是瘋狂的經歷,並強制你的漂亮的代碼庫進入一種新的格式,必須真的受傷。 – djna

4

對邁克的所有應有的尊重,如果你不能擊敗他們,加入他們。確實,正如djna所建議的那樣,學會容忍醜陋。在整個職業生涯中悄悄地對抗這場戰鬥之後,我提出了這個建議。

我相信Allman風格的編碼在幾個有意義的重要方面是更好的,從代碼對齊開始並明顯地闡明代碼塊。 Allman風格的人傾向於那些贊成/容忍更多地使用垂直空白的人來幫助澄清哪些事情是一起進行的,以及何時開始一個新的步驟或階段。在我自己的軼事研究中,除了向先前的先例致敬之外,最經常引用的主要優點是K & R是那些喜歡在一個屏幕上看到更多代碼的人喜歡的風格。是的,這是事實,這是主要原因。代碼密度。我認爲,一旦我們在90年代初超過了80 x 25個字符的控制檯屏幕時代,這個問題就已經死亡,但可惜,這看起來並不重要。因此對於那些喜歡代碼密度的人來說,他們一次只能在一個屏幕上看到更多的代碼,所以我們忍受着數百萬行的K代碼風格。*嘆息*

底線:你不能贏得宗教戰爭。這是不值得的努力。在羅馬時,照着羅馬人的方式去做,只要學會與現實生活在一起。這是一個在心理上打擊我們的問題,因爲它關於權力和控制。但我們都明白,有些事情我們根本沒有合法的權力或控制權,所以讓這些事情去學習適應。這確實是解決您軟件開發事業的正確方法。

+5

我的確瞭解到,即使有證據表明他們錯了,也不能改變自己的宗教信仰。 但是,目前,我在公司內部「擁有」的大多數代碼中,我將它作爲Allman離開它。一旦我被迫再次處理大量的K&R,我可能會尋找,或者寫一個IDEA插件,讓它看到Allman並保存K&R。倔強?也許。但我拒絕通過代碼來減緩速度。 – Mike