對於程序員來說，什麼叫良好的編碼習慣，怎麼樣養成良好的編碼習慣？

12-29

經常在簡歷上看到要求有良好的編碼習慣，那麼什麼叫良好的編碼習慣呢？作為一個程序員，又應該怎麼樣去培養良好的編碼習慣呢？求問？

控制住自己想裝逼炫技的慾望

我理解的良好編碼習慣，做到這幾點就差不多了。
1.變數，類，函數命名，資料庫欄位等等要和公司編碼風格相同，比如公司使用CIQMS_DECL_GOODS這樣命名，你非要這樣CiqmsDeclGoods，那這個就不是很好的習慣。
2.寫好注釋，不用很細緻，但是需要在難理解的地方寫上業務邏輯或者實現的功能，利人利己。另外最好每次都在更改，新增代碼時註明誰在什麼時候做的工作，這樣一方面能確認責任，另一方面搜索自己名字能快速定位自己寫的代碼，輸入法應該都有自定義短語的功能，我定義addby自動輸入add by kevin.liu at(當前時間)。
3，剩下的這條不是太重要，但是能做到也是很好的，代碼塊之間留不留空行，是這樣的
if(true) {one line code}
還是這樣的
if(true)
{
one line code
}
這些細節能注意就注意下吧

很多回答了命名，縮進等，我補充幾點：1、能夠簡單的方式就用簡單的方式實現，效率低沒關係，不優雅沒關係，不容易出錯，容易完成就行。當然關鍵代碼除外，非常榮幸的是99%都不是關鍵代碼。比如，要處理一組數據，大小可能不固定，你可以用動態鏈表，動態分配內存。但是如果數據數量可以預知，比如一個班的學生，那麼200個足夠了。最簡單的直接用靜態數組申明一個200的數組。裡面加個超出200異常就好了。不要說浪費內存，這點內存沒啥用。何況動態分配容易產生碎片，不一定就省內存。
2、簡單的事情重複做。你在做的某個功能或代碼片段，你之前有相同或者類似的，複製過來，要改的改下。不要每次去創新，創新之後還把以前的代碼也去改了。除非以前代碼有bug，否則不要這麼做。也沒必要重新去抽象，搞成對象，繼承啥的，最好的代碼復用一個是做成類庫，第二個就是複製黏貼。除此之外的代碼復用，很可能只是個願望。
3、預防bug思維。編碼時思考下如何能減少bug出現幾率，而不是先急急忙忙把功能完成，靠事後去發現bug。總有些參數你認為一定是某個樣子的，比如一定是非0，那麼你加上assert。在當初看來可能完全沒必要，因為這個參數真的不可能傳入0。但是代碼是會變的，相信我說的這點，這跟人是會變的是一個道理。代碼裡面加上調試開關，在調試狀態輸出些關鍵信息出來。也可以加入些自檢代碼，比如有些數據是有關聯的，檢查下這些數據關聯性是否還一致。比如學生數據有指向班主任，班主任下面掛有學生隊列/數組，自檢的時候可以檢查下關係是否一致。這個自檢可以在某個入口每次都調用，或者被其他調試代碼調用。正式版本不會出現。
4、演算法邏輯要簡單。需要演算法的，邏輯複雜的做成類庫，比如排序。其他代碼都要追求簡單2字。
總得來說，編碼就是要正確，完整，易用，不要炫技，勿忘初心。代碼平凡不可怕，平凡才可貴。

謝邀。我覺得良好的編碼習慣，這是一個很大很大的概念。簡單說幾點吧，拋磚引玉。

遵循特定的編碼規範，可以是你一貫的規範，也可以是你參與的項目所制定的規範，比如你參與WebRTC的開源項目，就要遵循它的規範，你參與Node.js的項目，就要遵循它的規範，而不是自己搞一套，弄得不和諧。
代碼邏輯清晰，剛剛好能滿足需求和業務即可，不要過度複雜化、炫技，也不要拎不清，在不合適的架構上硬撐
代碼面向讀代碼的人來寫，力求簡潔，自解釋，不需要注釋

---2017.02.23更新一下---
解釋下第3點，不能自解釋的部分，需要有注釋，但要避免過度注釋、注釋與代碼脫節、注釋混淆代碼原意等狀況。

Production support我做過幾年，因為.net、db、infrastructure都會。見識過各種個樣的production issue，看過50個以上不同的程序員的代碼。很多人早就跳槽走了，留下沒有注釋沒有說明文件的代碼。出了production issue之後，只能打開來看，到底幹什麼的，怎麼實現的，為什麼會出問題。
一開始很不習慣，看的很費勁，後來就當小說看了，只不過每個人的寫作風格不一樣。代碼的好壞也像小說一樣，沒有比較就沒有傷害。有的人的代碼就是簡潔明了，閱讀效率高，邏輯縝密，運行速度快，易增改。有的人的代碼loophole一堆，格式亂七八糟，前言不搭後語。作為一個曾經奮戰在一線的IT滅火隊員，我就想說說我喜歡的代碼。

1. 格式與注釋
格式與注釋是起不到邏輯作用，但是格式可以使團隊合作效率更高，代碼更易於維護，在緊要關頭，節省下來的都是救命的時間。我還記得我的第一任mentor，他嚴格要求我的代碼每起一行要有幾個tab，逗號放在列名前面，等等。不符合格式的代碼交過去，他一概不看，打過來改格式。我真的受益匪淺。

2.代碼結構的冗餘
說話不能太啰嗦，但也不能太精鍊。人家用2000行實現的功能，有的阿三900行就能寫完。但是當日後需要拓展和修改的時候，你就會發現那些極端精鍊的代碼如纏在一起的死結，很難解開或者插東西進去。好想懟回去說，你炫技你自己去改好不好，不要甩鍋給我。

3. 效率
講真的，我最不喜歡看.net developer寫的db代碼。他們還特別愛寫。我不否認有好的。但是很多都是一看就是那種急功近利，為了趕緊把功能實現，不惜table scan犧牲performance的垃圾代碼。一看到就覺得很不負責任。好好設計好流程和結構，把影響performance的十大因素列印出來貼在桌前，每次開寫前麻煩默念一遍好不好。

Support的辛酸史嘮叨了半天，我還得回去幫人家debug...

代碼大全，代碼整潔之道，兩本書去看

請搜華為編程規範

越是牛逼的人越不願意注釋，結果他們回頭看自己的代碼想跳樓。發現以前的自己傻逼一般的附體。

我的新浪微博號：許悍匪求關注

放半個月至少保證你自己能夠秒懂

這是最低標準了

絕大多數程序員寫的代碼就是一坨屎，寫好代碼最重要的是有寫好代碼的意識和慾望，說白了就是要自我要求高一點。

所以，當題主問出這個問題的時候，已經比很多程序員都強了。因為，絕大多數程序員都沒有學習「如何寫好代碼」。

對於想寫好代碼的同學，強烈推薦《clean code》，雖然是用java表達作者的觀點，但是語言只是表達的載體，思想適合所有編程語言。

這個問題對於不同語言，會有不同細節和要求。但是在我目前的認識，我覺得好的編程習慣應該有且不限於：

有效性。如果是寫給自己用的，那就不用說了。主要說的是要發布的、完整的、項目，下同。我覺得這一條包括了正確性和安全性。首先代碼要能切實完成一個功能。其次，要有防患意識，對於可能出現的如輸入不正確、邊界情況、溢出等要做好預算，怎麼處理，用戶給你亂搞也不至於讓你的程序炸掉。
兼容性。除了跟平台相關的兼容問題，還有代碼的二進位兼容問題。不要輕易修改代碼，不能想改就改，想移就移。暴露的介面的設計要合理，設計好的就不要輕易改。至少要說明好，在1.0.x系列要兼容，在2.x.x系列要兼容等。
可擴展性。在寫代碼前就要考慮好了，怎樣寫的代碼易於擴展，易於版本升級。簡單點說，就是如果你想繼續增加新的功能，你可以直接往上加，而不是為了增加這個功能你要做大量的修改和重構。
利於版本管理。比如對 diff 友好，方便 code review。比如列參數，有兩種寫法：
double x, y, z;
double x; double y; double z;
這兩種有什麼不同呢，如果我要新增加一個變數 double n，做一下 diff，第一種：
- double x, y, z; + double x, y, z, n;
變得多了要多花個兩眼才能看得出來，而第二種：
double x; double y; double z; + double n;
一眼就知道變化了什麼。類似的還有參數列表，初始化列表等等。當然還有人提到的，能讓下一任拿到這個代碼的能快速上手，熟悉，也是的。
測試。對代碼的正確與否，效率高否，要做測試，做 profiling，不要想當然，現在有那麼多好的測試框架，拿過來，時間充裕就多寫點case。

還有很多很多，不同語言的風格會不一樣。可以參考 Google 的 styleguide google/styleguide
有中文版，當然資源就少，就5種語言Google 開源項目風格指南 (中文版)

先寫偽代碼。

良好的編程習慣就是：
裝完逼之後，過兩年回來還知道自己裝的什麼逼，而且還覺得很牛逼。

要具體分析。

有的時候，很多高效代碼，普通人是看不懂的。

代碼讓不同的下家接手時理解邏輯耗時最低

從網上直接粘貼代碼的時候把縮進，中文亂碼和拼音變數名整理一下：）

多看書，多看代碼。

看看書上的設計模式，編碼習慣是什麼樣的。
看看有名的開源代碼是怎麼寫的。

盡量學習這些經典的編碼風格，這樣里的編碼習慣就是好習慣。

當然，按照老大制定的編碼規範寫代碼就是好習慣

注釋這東西，我一直覺得，只有
代碼不清晰，文檔不清晰的時候才有用
——當然，這種情況才是正常情況
比如一個「兼容」方法，一個「邏輯糖」

遵守代碼規範和命名規範，
合理使用版本管理，
完善項目文檔…
在我看來是最好的編程習慣吧

1、寫關鍵注釋，不要寫無意義的注釋

2、重複的內容要寫函數，函數的大小要適當

3、變數、函數的命名要望文生義

4、調用關係要單項，不要雙向調用

我感覺，良好的編碼習慣應該建立在代碼可維護性上。有人提到簡單實現，但是我並不是完全贊同這種說法，因為這本身已經是另一種範疇。自然簡單實現沒有錯，適當在內存中增加點冗餘可以提高代碼的可收縮性。但是良好編碼他並不是這種狹義的解釋。

真正的良好編碼是沒有標準的，no standard english一樣，所以這是種相對標準。但是也有方法讓大家去適應。

首先是代碼簡潔，這種代碼簡潔比較強調風格一致，變數命名，縮進。這很基本，分文件分模塊這也不用說，即便不知道，你多練習練習基本就懂個大概了，大家都說了我也不詳細展開，但最重要的還是變數命名，取一個極具代表性的名字可以讓別人一目了然。最好多看看開源項目，看看他們怎麼命名和編寫代碼的。這一步是永無止境的，多去看才會有收穫。另一個值得強調的是，不要吝嗇回車，適當的空行能夠保證代碼思路清晰，就算多敲幾行空行，編譯出來的程序也不會變大。

其次是注釋。注釋不是讓你從頭到尾全部標註，而是要標註的恰到好處。什麼是恰到好處這就看每個人的判斷了，但是大題不會偏離，基本上就是在Bug容易產生的地方標註一下什麼情況會出錯或者注釋一下設計思路等等，仁者見仁智者見智咯。

其實還有一個，這個只是一個建議，可有可無！多注重分層和解耦。代碼耦合度高的基本上缺少了優雅，所有代碼都可以在一定程度上解耦合，但這不是剛需，還要看情況。解耦合必定會增大系統體積。

最後一個層面是自身的修為。良好的編碼習慣，如果只談注釋怎麼寫縮進怎麼敲的話分明是在耍流氓。編碼習慣不應該和編程語言隔開來談，因為不一樣。
這裡建議大家自行查閱自己用來吃飯的語言在Github上面的開源項目，最好是大廠的，微軟，Google都可以看，不懂就百度這樣才能漲知識。最好能了解本質。

就這樣，向大家拜個晚年
以上