我是否應該匹配上一位作者的大括號使用情況？

Question

在處理來自多個作者的代碼時，我經常遇到大括號首選項（同一行vs新行）的問題。當涉及到匹配現有的風格和使用自己的偏好時，它是好的/壞的練習還是非問題？

如果您將新代碼添加到類中而修改現有代碼，情況是否會發生變化？最後，如果風格應該匹配，比賽應該傳播多遠？即，文件，類，子類等

實施例：

if(this) 
{ 
    doThat(); 
} 

比。

if(this){ 
    doThat(); 
} 

Answer 1

一般來說，格式不一致的代碼比使用自己的格式格式化的代碼更難閱讀和理解。

在開源項目上工作時，與使用的樣式相匹配被認爲是禮貌的。對於您不會共享的代碼，請遵循樣式或通過重新格式化器運行所有現有代碼。

Answer 2

試着與同事交談，並決定一致的風格。一旦你這樣做了，就用這種風格編寫所有新代碼，並在必要時轉換舊代碼。這是該項目及其工作人員特有的問題。

在罕見的情況下，你不能達成共識，我不會太擔心;世界上有太多的錯誤讓人們花時間移動大括號。 ：D

Answer 3

如果很多代碼已經簽入到版本控制系統中，這很重要。單純的支架風格改變會在歷史上出現很多嘈雜的變化。我不會爲了自己的緣故去做。你在羅馬......

Answer 4

如果你將分享這個，匹配他的風格的一致性。如果沒有，做你覺得舒服的事情。我個人比較喜歡你的風格。

Answer 5

無論您在何處放置大括號，代碼明智都無關緊要，它只是一個偏好問題。更有經驗的編程人員傾向於將其放在同一行，但我喜歡將它放在下一行，因爲它幫助我更輕鬆地看到代碼塊。如果你希望編碼習慣儘可能花括號，然後諮詢你的團隊，並選擇一個，但他們可能會笑lol

Answer 6

沒有什麼比令人討厭的代碼更令我厭煩，並發現無數的不匹配風格灑在整個。如果您要與程序中的某個人進行協作，不論是明示的還是隱含的，都應該使用標準。像花括號一樣簡單的東西並不重要，但是當你的項目得到管理層的審查時，你甚至無法得到匹配整個項目的一件小事情。或者，如果您正在與朋友一起開展個人項目，然後決定讓其他人加入，該項目將開始看起來不專業。在這樣的團隊中工作時，我會說，這與個人的意見不同，而不是團體標準。