知乎作者@葉小飛:
作為Oppo Reno2 超級夜景核心開發人員和奔馳San José Pilot落地工程師之一，我寫代碼基本盡可能地遵循Google Style. 在這里寫幾個自己的習慣+Google Style里面幾個常用的要點。

自己的習慣

動手寫代碼前盡量做到胸中有丘壑。現在這世界講究格局，寫代碼亦然。 我寫代碼前一般要先回答這么幾個問題——這段代碼的核心功能是什么？實現它的核心功能需要實現哪些functions? 這些functions需要設計哪些相應的class？這些class如何盡量做到hierarchy, 能否從已有的代碼庫里進行繼承來避免重復開發？回答了這些問題后我才會動手寫，這樣避免寫代碼時東寫一塊，西寫一波以及重復作業。

能高效一行寫完的絕不寫兩行。 舉個簡單的python 例子，有人通過if else總共四行代碼來判斷return A or return B, 其實完全可以縮成一行：return A if something else B

做好文檔規整。 程序員的工作不是學完代碼就拉倒的，還包括整理好自己代碼的文檔介紹，一方面方便工作交接，讓領導更實質性地看到你的功勞，另一方面方便給自己理清思路，同時為很久以后溫習這份代碼做準備。

坐姿端正，保護好你的頸椎。 老程序員都懂，頸椎不好多么影響工作效率。寫代碼時盡量用大屏，這樣不用低頭去寫，坐姿正確對頸椎、老腰都好，可持續輸出才是王道。

Setup好用的IDE事半功倍。 我寫C++一般用Visual Studio, 寫Python用Pycharm

C++ Google Style 里幾個常遇到的要點

頭文件引用：一般來說，每個cpp文件都要對應一個頭文件。在你的.cpp 或者.h file里只引用你用得到的頭文件，以此減少compilation時間。另外，盡量避免transitive inclusion(比如你引用的某個頭文件A引用了頭文件B，所以你的cpp文件雖然需要用到B的函數，但沒有單獨引用頭文件B也可以正常compile 和運行，這就叫transitive inclusion)

Struct只用于passive object, 其他一律用class

變量命名法則： 變量名稱一定要反應它的用途。變量名字太長沒關系，首要讓人明白它是做啥的。盡量不要使用非常見縮寫，例如，digital_signal_processor可以縮寫成dsp, 但是不能寫成dig_sig_process。

注釋盡量保持風格一致，比如你上一段用了//,下一段代碼用/**/注釋就屬于風格混亂。每個函數下面都要有注釋代碼，來解釋input/output 是什么，這段函數用來做什么

如果你的函數不需要改變argument里某個變量的內容，那么記得加const. 方便讀者一目了然這個函數做什么用的，方便compiler更好的做type checking.如果你代碼里有大量的指針，建議使用smart pointer， 以防你漏刪指針造成內存泄漏。

知乎作者@平凡：

寫文檔能力很重要

團隊作戰會發現很多時間華仔寫文檔上，我之前實習的那個軍工保密單位，一個項目會由好幾個兄弟單位一起齊頭并進，所以保持文檔一致是非常重要的，二我再那段時間寫過一個100多頁的文檔，并最終600多頁的文檔是由我和一個小伙伴合并完的，其中很多工作花在命名一致上，那段時間真讓人頭禿。

結對編程

有能力的話要結對編程，既可以讓你精神愉悅

還能在你休息的時間review代碼

干凈整潔的編程環境

其中也包括了愉悅的心情，如果桌面臟亂差，非常影響心情。

心情愉快的前提下編程效率會大大提升。

習慣去看源代碼

網上的攻略再好，也是二手資源

不要重復造輪子

要相信前人的智慧和尊重大家的鑒別能力

知乎作者@王哲：

關于代碼本身

“要懶惰，不要懶惰”：如果發現重復的模式，思考如何抽象出來，避免重復的寫類似的代碼。不要”懶得“抽象。懶得及時抽象，會讓代碼重構變得越來越困難。

最簡單的例子是寫function抽象，復雜一點的可以通過meta programming，既寫生成function的function抽象。這個各種語言提供的方法不一樣，有些語言更加靈活，比如Clojure一類，幾乎可以通過宏隨意構造新語法的；有一些比較不方便，比如Java只能通過設計模式實現某些抽象。

通過寫Generic operator抽象，就是可以動態dispatch的函數。

不要的代碼及時刪除，不要變成注釋。你的git會幫助你找回你刪除的代碼。

一個函數如果超過了50行，考慮拆解成多個函數。

盡可能分離純函數和非純函數。純函數就是那些無狀態、無IO的，相同的call永遠給你相同的結果。這些函數非常可靠而且容易測試；非純函數就是IO、有狀態的，他們的測試需要Mock，而且不穩定。所以，盡量把非純函數推到程序的邊界上，讓內核盡可能的保持純潔。

關于注釋

寫注釋的時候應該記住，你的注釋是寫給其他人和未來的自己看的。不要寫過多解釋代碼的注釋，要寫假設、注意事項、例子等等對用戶有用的信息。這里用戶包括兩類：使用功能的人和將來維護拓展功能的人。

注釋主要分成兩種，一種是給接口寫的，一種是給實現寫的。

寫給接口的注釋，應該包括：input requirementoutput assumptionpossible raiseexamples寫給實現的注釋，應該包括：

• Abstraction function，就是 實現是如何映射到目標數據結構的

• Representation invariant，就是 實現的時候那些數據結構是有效的

關于測試

寫函數的時候問自己，這個函數容易測試嗎？如果容易，寫幾個test case。如果不容易，拆解函數成容易測試的。

新的一年，小夕給大家拜年啦！

祝小伙伴們在新的一年里，

算法如巧克力般硬核，

代碼如牛奶般絲滑。

告別996，

擁抱財富自由！

<<<? 滑動打開信封，查收祝福吧? >>>

后臺回復關鍵詞【入群】

加入賣萌屋NLP/IR/Rec與求職討論群

后臺回復關鍵詞【頂會】

獲取ACL、CIKM等各大頂會論文集！

總結

以上是生活随笔為你收集整理的新年立个小目标！代码写得更规范！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。