為什么強(qiáng)調(diào)代碼風(fēng)格
不同的語(yǔ)言枷莉，不同的項(xiàng)目娇昙，都有自己的風(fēng)格，就像每個(gè)人都有自己的特點(diǎn)一樣笤妙。
代碼風(fēng)格是一個(gè)不容易引起注意冒掌，但又回避不了的問(wèn)題。一個(gè)人獨(dú)自開(kāi)發(fā)的工作蹲盘，對(duì)代碼風(fēng)格是沒(méi)有明顯感知的股毫，但一群人一起開(kāi)發(fā)就不一樣了。當(dāng)吐槽別人代碼的時(shí)候召衔，或?yàn)樽约簬讉€(gè)月前的代碼汗顏的時(shí)候铃诬，很可能是因?yàn)榇a風(fēng)格上有了分歧，該引起所有人注意了薄嫡。
一個(gè)項(xiàng)目代碼風(fēng)格的確立和維護(hù)氧急，都是需要耗費(fèi)時(shí)間和精力的，但從下面幾點(diǎn)好處看毫深，維護(hù)代碼風(fēng)格是件高收益的事：
- 提高閱讀代碼效率
- 減少語(yǔ)法吩坝、邏輯理解的歧義，方便更快了解別人的代碼哑蔫，減少溝通成本
- 杜絕了以后關(guān)于大括號(hào)是否需要換行等風(fēng)格問(wèn)題的低效爭(zhēng)論钉寝，團(tuán)隊(duì)更加和諧
- 新人依據(jù)確立的規(guī)范快速融入?yún)f(xié)作弧呐，減少剛?cè)胧謺r(shí)容易犯的錯(cuò)誤（因?yàn)榍叭瞬冗^(guò)的坑可能已總結(jié)成規(guī)范）
- 保持心情愉悅…
代碼風(fēng)格內(nèi)容
此處討論的是一個(gè)具體項(xiàng)目的代碼規(guī)范，這樣的規(guī)范就應(yīng)該在項(xiàng)目組內(nèi)經(jīng)討論確立后以文檔方式儲(chǔ)存嵌纲，方便成員查看和優(yōu)化俘枫。
文檔要求盡可能精簡(jiǎn)，不能事無(wú)巨細(xì)地羅列所有規(guī)則逮走，只需挑出視覺(jué)效果最明顯鸠蚪、最基礎(chǔ)的那部分規(guī)范。規(guī)范可包括以下幾項(xiàng)內(nèi)容：
- Objective-C/Swift基本編碼規(guī)范
網(wǎng)上可找到較多詳細(xì)的規(guī)范參考文檔师溅，比如： Objective-C-Coding-Guidelines-In-Chinese , Objective-C編碼規(guī)范[譯] 茅信。
不需要完全照搬別人總結(jié)的規(guī)范，對(duì)其適當(dāng)增刪后采用墓臭。 - 本項(xiàng)目專(zhuān)屬的一些編碼約定
比如Debug Log的輸出格式蘸鲸，代碼行最長(zhǎng)字符數(shù)限制，類(lèi)的前綴名窿锉，文件酌摇、文件夾命名組織方式等（“對(duì)程序員而言，命名就是工作的本質(zhì)嗡载，函數(shù)名窑多、變量名、方法名鼻疮、屬性名怯伊、類(lèi)名和框架名等都必須具備”）。 - 項(xiàng)目?jī)?nèi)一些功能模塊的使用判沟、編寫(xiě)規(guī)范
常用工具類(lèi)耿芹、管理類(lèi)的梳理總結(jié)，客戶(hù)端生成文件夾的結(jié)構(gòu)挪哄，數(shù)據(jù)庫(kù)字段描述等吧秕。
后面兩條的內(nèi)容可以說(shuō)已經(jīng)超出了代碼規(guī)范的內(nèi)容，但對(duì)減少大家溝通迹炼、學(xué)習(xí)成本是有益的砸彬，其內(nèi)容可以不放在代碼規(guī)范中，但同樣需要文檔歸納總結(jié)（雖然大家都不愿寫(xiě)文檔斯入，但這樣的文檔的作用絕對(duì)不比代碼少）砂碉。
風(fēng)格的確立
一個(gè)組里組代碼風(fēng)格的確立，一定是一個(gè)大家一起商討的過(guò)程刻两。
一般先由個(gè)別成員（有時(shí)候1個(gè)人的效率>多個(gè)人）結(jié)合項(xiàng)目舊有的代碼增蹭、編程語(yǔ)言的特點(diǎn)進(jìn)行整理后，大家再一起討論進(jìn)行刪減補(bǔ)充磅摹。
商討過(guò)程少不了半天時(shí)間滋迈，期間怎么吵都可以霎奢，但最終大家要達(dá)成一致意見(jiàn)。討論結(jié)束后饼灿，持有不同意見(jiàn)的人也得遵守已成文的規(guī)范幕侠，所以大括號(hào)是否該換行這類(lèi)問(wèn)題就要放在這個(gè)時(shí)候激烈碰撞。
沒(méi)有最好的規(guī)范碍彭，只有大家普遍認(rèn)可的規(guī)范晤硕。
維護(hù)規(guī)范
確定一份規(guī)范文檔，只完成了統(tǒng)一代碼規(guī)范的一半工作硕旗，更重要的另一半窗骑，就是踐行該規(guī)范了。
誰(shuí)都有習(xí)慣一時(shí)改不過(guò)來(lái)的情況漆枚，更有編程盡興就不注意多寫(xiě)或少輸入了一個(gè)空格的時(shí)候，所以Code Review的一大任務(wù)抵知，就是細(xì)致檢查隊(duì)友是否遵循了規(guī)范墙基，幾次下來(lái)大家就都長(zhǎng)記性了。但是風(fēng)格錯(cuò)誤的檢查刷喜，應(yīng)該只是前幾次Code Review的重要內(nèi)容残制，之后的Code Review就不應(yīng)再過(guò)多談?wù)撨@些小細(xì)節(jié)了。
至于老代碼是否需要按新規(guī)范來(lái)改掖疮，建議還是別動(dòng)初茶，工程可能非常巨大。當(dāng)做新功能需要修改到老代碼時(shí)浊闪，順手改改那一塊代碼就行恼布。
再就是代碼規(guī)范的更新，雖然這種文檔內(nèi)容一般不容易有大的變動(dòng)（除非像Objective-C轉(zhuǎn)Swift之類(lèi)大動(dòng)作）搁宾，但真要新增規(guī)范折汞、或者剔除一些老舊規(guī)則時(shí)，要積極提出修改建議盖腿，及時(shí)更新文檔爽待。
挖個(gè)坑下篇文章再總結(jié)下現(xiàn)在養(yǎng)成習(xí)慣遵守的一些編碼規(guī)范。
