撰寫代碼，實質是在梳理邏輯，為了完善整個邏輯流程，我們借用編程語言的變數、函式、流程控制、回圈、注釋、方法等串接起來，完善一套系統的邏輯，
為了完善這套邏輯，我們借助了許多工具：設計方法、架構設計、專案組織等，
意識到沒有，代碼的好壞一定程度上可以從邏輯層面評判，
- 符合邏輯，不一定是最優的代碼
- 不符合邏輯，一定不是好的代碼
從這層面來看，梳理邏輯極為重要，邏輯通了，剩下的就是實作了，
邏輯的串接靠的是編程語言的變數、函式、流程控制、回圈、注釋等，
本文從這些層面講述，如何撰寫可讀代碼，
小編推薦一個學C語言/C++的學習裙【 712,284,705】，無論你是大牛還是小白，是想轉行還是想入行都可以來了解一起進步一起學習！裙內有開發工具，很多干貨和技術資料分享！
0. 規范
絕大多數的人，不會從零完整的完成一個復雜的專案，大多是團隊共同合作，完成一個大的專案，
這個時候，假如你是中途參與進來，你在實作邏輯的時候，你是照著自己的邏輯來還是依照團隊的風格來，
比如專案組織，命名等...
依照團隊的風格來
尤其針對復雜的上線的專案，完整的理解整個專案都存在困難，這個時候，風格統一尤其重要，
是的，這個時候，風格一致性重要，當然具體的實作邏輯，還是應該遵從易于理解這個大方向，
1. 編程語言規范
準則：堅持編程語言的風格
每門編程語言，都存在一定的規范，這個時候，編程語言的整體規范需要遵從，
大家可能會多參考 google 出品的各種編程語言規范，方向沒錯，
2. 命名
- 變數
- 函式
- 方法
準則：易于理解
如何做到易于理解：
- 專業的單詞：使用領域內的單詞
- 避免空泛的名字
- 具體的名字
- 變數名帶上更多細節
- 不使用令人誤解的名字
- 布林值命名
- 不建議使用的單詞
2.1 領域內的單詞
這個和專案相關，比如系統是個智慧零售后臺，那么領域內單詞多是：顧客、商品、商鋪、店員、店長、價格等，
- customer
- produce
- shop
- shopLeader
- price
2.2 避免空泛的名字
變數的命名一般要賦予一定的意義，極少情況下可以使用沒有什么意義的單詞，比如最常見的：
var (
numberOne int
temp int
numberTwo int
)
tmp = numberOne
numberOne = numberTwo
numberTwo = tmp再比如：
var i int
for i=0;i<10;i++{
fmt.Println(i)
} 這種沒什么意義的單詞，一般適用于區域作用域，
盡量少用，
2.3 具體的名字
完成什么任務就使用什么單詞，一般變數使用名詞居多，函式使用動詞開頭居多，
函式多用動詞，變數多用名詞
比如：
var toString = func(){}
var serverLoop = func(){}
var pages int
var userName string2.4 帶上更多細節
一般命名不建議過長，也不建議過短，那多長，多短合適呢？
最長三個單詞的長度吧
如何帶上更多的細節，
- 嘗試使用后綴
- 嘗試使用單位
- 嘗試指向具體的細節
比如：
var timeIntervalMs
var lengthCm
var delaySecs
var sizeMb
var maxKbps
var degreesCw
var numberMax
var numberMin
var numberFirst
var numberLast贈送幾組對仗的后綴：
- max/min
- first/last
- begin/end ...
ServerCanStart() 不如 CanListenOnPort()2.5 不使用令人誤解的詞
比如：Filter 在資料庫操作中容易使用這個單詞，這個單詞沒有帶上更多的細節，實質上在使用的程序中，還是需要查看撰寫的SQL 陳述句等才能知道具體的過濾細節，整體思考多了幾步，不易讓人理解，
建議多讀幾遍自己命名的單詞
2.6 布林值
提到布林值，因為就存在兩種結果，所有，一般使用是否這樣意思的詞，
比如：
var (
ok bool
notOk bool
)
var (
is bool
)
var (
has bool
)
var (
found bool
)
var (
should bool
)
var isCompany = func(){}
var isVip = func(){}
var hasSpace = func(){}2.7 不建議使用的單詞
- get
- read
- util
恰恰這幾個單詞，在寫代碼中最容易使用，選擇替代方案，
贈送一波動詞：
- send
deliver、dispatch、announce、distribute、route
- find
search、extract、locate、recover
- start
launch、create、begin、open
- make
create、setUp、build、generate、compose、add、new3. 設計
一份好的幻燈片演示設計需要考慮什么？
- 符合場景的配色，確定原始基調
- 符合場景的事物，借用來表達觀念
- 統一整體風格
- 對齊、重復、親密、比較
看到沒，幻燈片演示設計，強調場景化，選擇適合場景的主體和配色，比如黨政風格，當然選擇國旗色；比如學術答辯，當然選擇藍色；比如手機發布會，當然使用暗黑科技風格...
所以代碼也需要場景化，選擇符合場景的單詞等
這里以設計的四個規范類比代碼的組織，
3.1 對齊
編程語言為什么強調縮進？難道不是為了閱讀代碼的人更容易看懂代碼嗎？寫代碼的人更容易組織代碼嗎？僅僅是設計者為了好玩？
當然不是，
舉例：撰寫web路由和控制器
// student.go
func Register(r *gin.Group) {
r.POST("/v1/api/students", PostHandler)
r.GET("/v1/api/students/:sid", GetHandler)
r.PATCH("/v1/api/students/:sid", PatchHandler)
r.PUT("/v1/api/students/:sid", PutHandler)
r.DELETE("/v1/api/students/:sid", DeleteHandler)
}- 放眼望去，確實知道實作什么任務
- 風格統一
- 整整齊齊
這個例子可能解釋對齊，不夠友好，
再舉個例子：
CheckFullName("No Such Guy","", "not match found")
CheckFullName("John", , "", "more than one resule")3.2 重復、親密、比較
當然，作為程式員，最應該避免的其實就是寫重復的代碼，一般的做法往往是提煉，將重復的抽象出一個函式之類的，這里的重復，是風格的統一
// teacher.go
func Register(r *gin.Group) {
r.POST("/v1/api/teachers", PostHandler)
r.GET("/v1/api/teachers/:tid", GetHandler)
r.PATCH("/v1/api/teachers/:tid", PatchHandler)
r.PUT("/v1/api/teachers/:tid", PutHandler)
r.DELETE("/v1/api/teachers/:tid", DeleteHandler)
}可以結合比較下 student.go 和 teacher.go
這樣的組織方式，講道理，并不太會給閱讀代碼的人帶來太多的認知負擔，
- 一致的順序
- 始終一致的使用，使用戶其實閱讀一個，類似的都能秒懂
3.3 留白
設計領域頁面的設計，并不強調內容越多越好，恰當的在頁面上留有空白，使整體設計有呼吸感，
那編程如何實作留白？
- 恰當的換行，使相似的內容更緊湊
- 提取，使用方法來組織不規范的東西
- 代碼分段
假如你一個函式需要寫 100 多行，不好意思，我可能建議你，不要這么做，
- 拆分，邏輯梳理、提取方法
- 盡量維持最長 30～50行左右（這樣使螢屏能裝載下，一次就能完成的閱讀整個函式的邏輯）
4 注釋
準則：幫助閱讀代碼的人對代碼了解的和寫代碼的人一樣多
- 什么時候不需要注釋
- 什么時候需要注釋
4.1 什么時候不需要注釋
是的，前文的一系列準則，命名啊之類的，是內容，也是注釋，通過閱讀變數、函式名等就了解了代碼完成的任務，
這樣的地方不需要注釋，因為顯而易見，從代碼本身就能推斷事實，
有時候可能需要考慮是不是命名不好，導致需要注釋，這個時候，命名優于注釋，
給不好的代碼注釋，和在錯誤的路上持續努力一樣令人可怕，
4.2 什么時候需要注釋
- 關鍵點
- 缺陷點
- 常量
- 全域注釋
- 總結性注釋
關鍵點：
有些時候，僅僅靠之前的“表面作業” 已經不能完全能夠滿足讓人易于理解，這個時候需要在關鍵點添加注釋，
缺陷點：
是的，承認自己的代碼寫的不是最優的，僅僅只是實作，還存在更優的辦法，所以需要在有缺點的地方加上注釋，
常量：(各編程語言建議常量大寫)
給常量注釋，賦予了更多的意義，
比如：
NUMTHRADS = 8 // as long as it is >= 2 * number_processors, that is good enough.好，假如你正在優化代碼，看到這注釋，是的，你知道該如何調整了，
全域注釋：
一般在檔案開頭，表明檔案內代碼完成的任務，
總結性注釋：
一般函式開頭，表明函式代碼完成的任務，
其他：
潤色陳述句，言簡意賅由于冗長的解釋，
以上就是代碼表面整潔規范的標準和建議，希望大家都能敲出高效、整潔的代碼，
如果你也想要自學C語言，接受全面系統的指導，這里有一個交流群推薦給你，
不論是小白還是進階者，在這里都能獲得成長，群內含有，學習書籍電子書資源，素材包，還有免費教學課程哦~點我進入群聊
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/224949.html
標籤：其他