你如何與完全不同的編程風格的程序員合作？

Question

有沒有人與一個完全不同的編程風格的程序員合作？如何在不想刪除和重寫每個其他代碼的情況下一起開展活動？

Answer 1

選擇一個，並與它一起去。

如果你發現很難達成一致，走的時候，列出利弊，包括：自動格式化

• 工具支持（副手，我知道的Eclipse和Visual Studio可以做到這一點一個設置文件）
• 符合一般行業標準（太陽已公佈的標準規範爲Java，也許是你的語言等同？）
• 是否符合或修改預先存在的源代碼（如果在一種風格中有一百萬行代碼，將代碼更新爲新風格有多難？）
• ......這要麼你發現任何其他因素是非常重要的（這可以包括成本來熟悉新的樣式）

如果你發現自己與別人工作壓力太大固執地改變和適應，好吧，你有一個比衝突的代碼風格更大的問題，處理這個問題超出了範圍。

如果您是適應您風格的人，請避免聲明「如果我們選擇了我的 ......」。如果您已經就單一樣式達成一致，請完全承諾。

在談到這一點之前，你應該問自己：有一致的代碼有什麼好處？您可能會發現一致代碼的成本（煩擾其他開發人員）不值得。

Answer 2

我們同意標準的編碼風格，並以Visual Studio設置文件的形式強制執行它。

Answer 3

與其他開發人員溝通。 同意結合兩全其美的編碼風格？

Answer 4

這是一個人際溝通問題。相互交談。不通過代碼，親自。

Answer 5

• 使用與風格檢查插件組合的IDE（在Java的情況下 - 的Checkstyle，PMD）的領隊，甚至項目經理（如果一個技術人員）全時可以強制代碼風格指南球隊。

• 只是忽略了他的風格 - 我曾參與過一些開發人員將大括號放在新行上的Java項目，並且往往會忘記它們通常需要的空間 - 而且我對它沒有任何問題在第一週後。

• 討論代碼風格和妥協，然後應用第一點中提到的IDE功能。

Answer 6

你將不得不發明一些適合你們的風格並堅持下去。如果溝通是一個問題，只要堅持一個想法：「當我寫我自己的時候，我不會碰其他代碼」

Answer 7

當你說「編碼風格」，你的意思是格式或你的代碼結構的不同嗎？

至於編碼風格，團隊可能應該有一個樣式格式化程序，並在提交之前強制某種格式。這種合併方式不會令合併瘋狂。

對於代碼中的結構性差異，恐怕沒有簡單的解決方法。如果你是一個核心的意大利細麪條編碼器，而不是狂熱的對象編碼器，你將不得不坐下來討論這兩種方法，以及它們如何應用於你的特定項目。請記住，沒有絕對的答案，這一切都取決於上下文。 也可以嘗試訴諸某人尊重推薦最佳實踐，對代碼驗證進行代碼審查，並幫助確定常見方法（技術領導者或技術人員）。

Answer 8

我要回答與我有着截然不同的編碼風格的人相處所需的「軟技能」。一般來說，我嘗試着重於三個簡單的原則;專業，信任和自我。

就專業性而言，簡單的重寫或刪除某人的代碼是不可接受的，因爲他們的風格與您的風格不同。一個專業的方法是首先理解爲什麼我認爲我的想法/風格/喜好更好。然後，我希望與其他人坐下來討論我的觀點，這裏是重要的部分，保持開放的態度。僅僅因爲我喜歡我的想法並不意味着它是正確的或正確的。一個真正的專業人士將能夠並願意接受其他觀點同樣有價值並且來自不同的角度。

我個人需要信任我的開發人員。古老的說法是信任必須得到，而不是軟件開發。信任可以來自各種來源，如共享信息，想法和代碼。一個有生產力的團隊通常在開發人員之間有一種隱含的信任等級。

人們不相處的一個主要原因是自我。我們的自尊讓我們感受到了威脅，優越，尷尬和各種其他人類的情緒。拋開我們的自尊並與他人談論我們的問題總是一個好的開始。

Answer 9

我必須和開發人員一起工作，這些開發人員的代碼風格與我的開發人員有很大不同，並且作爲開發人員，您將學會如何處理它。

你有4個選擇， - 你可以將它們轉換成 - 你得到轉換 - 你提出一個公司標準。 - 你住在裏面。

如果它像是在類型前面加上變量，爭辯說一個變量應該足夠描述以便可以推斷它的類型。

personName vs sPersonName vs strPersonName < - 您會選擇哪一個？

如果你的意思是格式化， CTRL-A，KF < - 很好地格式化你的代碼在VS :)

Answer 10

我覺得很罕見的，只有一個其他開發人員與我必須在編碼風格一致，而不同的團體或項目有不同的風格。你必須學會​​適應不同的編碼風格。

如果只有你們兩個人，則只有你們兩個人誰需要對你要使用常見的編碼風格一致。

如果你不能在編碼風格一致，那麼你只需要對付它。試着以一種富有成效的方式工作 - 這意味着不要重寫其他人的代碼，只是爲了讓它符合你的風格。

可能有一些文體方面是麻煩的，而且最好把重點放在那些。風格可以很容易地變成宗教討論，所以關注變化的定量或經驗論證往往更有效。你的代碼的優美程度和物理美感可能無法贏得爭論 - 但展示一個風格變化會導致不必要的調試的案例可能會有效。

Answer 11

這取決於。

如果其他開發商並沒有特別隨和，那麼我傾向於只與他們的編程風格去就算我不同意，而不是強迫的問題 - 在這種情況下什麼更難受其真正的問題，他們的編碼風格或悲傷我會通過大驚小怪嗎？

如果其他開發商更開放的態度，然後我可能會討論事情像編碼/命名標準（我希望事情像整體架構將反正討論）

Answer 12

你編碼風格是不規範。 他的編碼風格不是常態。 規範是項目選擇的編碼風格，有時候是整個組織（並且應該記錄在某個地方），你們都必須遵守它。像Checkstyle（帶有Java）的工具可以用來確保一致性。如果您使用這樣的工具，請分發其配置文件。還爲IDE格式化配置分發文件。許多開源（或公司）項目都使用這些原則（例如，請參見XWiki的Java Code Style，Maven Code Style And Code Conventions或Apache Developers' C Language Style Guide）。這適用於分佈在世界各地的開發人員，不要告訴我這對於同一個房間的開發人員不適用。

如果你的項目沒有任何代碼標準，那麼它可能的時間來定義一些，我只是希望你能夠做到這一點作爲兩個成年人（實際上，這應該是一個團隊的決定）。如有必要，請提醒爲什麼統一代碼風格很重要（爲了更好的可讀性和差異性）。可悲的是，如果這不起作用，那就讓老闆爲你做決定吧。