※ 引述《stu87616 (DoubleLight)》之銘言：
: 我相信每個人應該多少都有像我這種自己養成的習慣
: 因為最近開始會經手多人共同的Project了，
: 開始擔心起這種自己的堅持會不會出現什麼麻煩事
: 各位版上先進，關於這種問題是怎麼處理的呢
Coding Style是一種習慣，每個人的習慣都不同
團隊合作的話
(1)有一份共通的文件讓大家Follow，通常都是比照公認的習慣
舉個例來說，python 有PEP8 http://legacy.python.org/dev/peps/pep-0008/
或是Java官網上的建議: http://bit.ly/1wWAL3I
也許和你的習慣不同，但是每個人都不同就會吵不完了
大家都讓步一點點，遵守一個共同的規範
ps 更大一點的公司，可能會有自己的style spec
這通常都是因為legacy code流傳下來的，但新創團隊，或是沒什麼特別理由的話
基本上照語言的建議版本是最快的方式
(2)運用一些工具確保大家都有遵守
以Java來說，凡是要動到production
(a)先用 http://findbugs.sourceforge.net
(b)是用 http://checkstyle.sourceforge.net 確保style
(c)送code review，讓第二個人給feedback，確實comment quality
(d)送QE做測試，檢驗unit test是否完整，code coverage如何
上code style更重要的，是git 的用法，開發通常會依循
http://nvie.com/posts/a-successful-git-branching-model/
確保新feature都有各自的branch，未來能比較容易維護
不然整天在那裡conflict，大概什麼都不要幹了…
(e)Merge 你的工作(feature/bugfix/...)到develop之後
送CI(我們大部份是使用https://wiki.jenkins-ci.org/)
(f)測完都沒問題，找PM背書，準備列入到下一次的production release
大致上的流程通常是這樣:)