咨詢(xún)電話(huà)
微信掃一掃
新聞動(dòng)態(tài)
代碼美化的藝術(shù)
網(wǎng)站建設 發(fā)布者:cya 2019-12-16 08:44 訪(fǎng)問(wèn)量:137
作者:敘帝利
鏈接:https://zhuanlan.zhihu.com/p/83249845
原本只是想簡(jiǎn)單的聊一下代碼格式化的問(wèn)題,無(wú)奈本文拖沓了很久,在此期間,我又思考了很多,我越來(lái)越覺(jué)得代碼格式化是一門(mén)藝術(shù)。為了襯托“藝術(shù)”二字,可能叫“代碼美化”更貼切一點(diǎn),但是本文的深度遠沒(méi)有標題那么宏大。
在我看來(lái),代碼質(zhì)量不僅體現在邏輯上,也要體現在形式上。尤其前端代碼,在日漸復雜的單頁(yè)面開(kāi)發(fā)中,代碼格式化不僅是為了美觀(guān),也是為了更好的閱讀及檢查。關(guān)于代碼的格式化并沒(méi)有統一的標準,每個(gè)人都有自己的見(jiàn)解,所以本文的目的以探討和推薦為主。
可能很少有人會(huì )去考慮這方面的問(wèn)題,畢竟美化插件都是現成的,比如常用的 Prettier,只要一個(gè)快捷鍵就可以迅速格式化,但是代碼格式化插件的標準并不一定是最好的。
本文范例主要以 Angular 為主,但是代碼美化的建議同樣適用于 React 和 Vue。
每行代碼多少字符合適?
關(guān)于代碼字符數一直是一個(gè)爭論不休的問(wèn)題。在 Python編碼風(fēng)格指導(PEP8) 規定了每行不超過(guò) 80 個(gè)字符。Prettier 默認也是 80 個(gè)字符。
贊成這條規范的人認為 80 個(gè)字符緊湊美觀(guān),在大屏顯示器也可以分多欄顯示。如下圖所示:
我最開(kāi)始也是贊成 80 個(gè)字符的建議,但是當我遵循這條規范寫(xiě)了近一年的 Angular 代碼之后,我發(fā)現這條規范有一些缺陷。
首先這條規范是 Python 編碼風(fēng)格的建議,而 Python 的代碼是以縮進(jìn)代表代碼塊,類(lèi)、函數等在定義時(shí)也沒(méi)有大括號及小括號,算上括號前的空格,這就比一般的代碼少幾個(gè)字符。
其次現代的編程模式大多是面向對象的風(fēng)格,類(lèi)的繼承、接口實(shí)現等都可能導致代碼很長(cháng),在 Angular 中可能還會(huì )實(shí)現多個(gè)鉤子函數的接口。
另外,Angular 的代碼風(fēng)格建議不要為了精簡(jiǎn)變量命名而損失易讀性,所以很多時(shí)候函數命名可能很長(cháng),再加上類(lèi)型系統及鏈式調用等,單行代碼很容易超過(guò) 80 個(gè)字符,這樣就會(huì )造成過(guò)多的折行。
下面是一段使用 80 字符寬度格式化的 TS 代碼:
我們再看一下擴大到 100 字符之后的效果:
這段代碼或許還不是最典型的例子,但是也能看出兩者的不同,在實(shí)際的業(yè)務(wù)當中,類(lèi)似的折行可能更多,而從我個(gè)人的角度來(lái)看,過(guò)多的折行反而破壞了代碼的完整度。目前常用的代碼寬度有三種,分別是 80、100、120,很顯然,80 太短,120 太長(cháng),以中庸之道,取 100 剛好。
代碼寬度對模板(html)的影響也很大,下面我們重點(diǎn)聊一下關(guān)于模板的格式化問(wèn)題。以下是使用 Prettier 的默認設置格式化的效果:
上面這種格式化方案非常普遍,但是我個(gè)人并不喜歡這種格式化的效果,原因有以下幾點(diǎn):
開(kāi)始標簽末尾的尖括號看上去有點(diǎn)突兀。
所有屬性全部換行,整體有些松散,模板代碼可能變得很長(cháng)。
標簽和屬性的區分度不高。
我比較喜歡下面的格式化方案,整齊緊湊,屬性之間相互對齊,標簽一目了然。
簡(jiǎn)單說(shuō)一下上面這種格式化效果的方法:需要使用 VSCode 默認的 HTML 格式化插件。在 首選項-設置-擴展-HTML
,設置 Wrap Attributes
屬性,選擇 preserve-aligned
(保留屬性的包裝,但對齊),這個(gè)選項允許單行顯示多個(gè)標簽。
Prettier 好像無(wú)法實(shí)現(有了解的朋友可以給我留言)。
最近在格式化代碼的過(guò)程中,我總結了一套排序規則及格式化建議,大家可以參考一下。
給元素屬性排序是一個(gè)可有可無(wú)的操作,但是合理的屬性順序同樣有利于代碼的閱讀及檢查。這和排列 CSS 屬性順序幾乎是一樣的。在編寫(xiě) CSS 的時(shí)候,我會(huì )刻意的按照以下順序排列屬性:
Positioning
Box model
Typographic
Visual
Misc
詳情參考 Code Guide,以下是元素屬性的排序建議:
模板引用變量
class
結構型指令
屬性型指令
雙向綁定
屬性綁定
事件綁定
五個(gè)及五個(gè)以下屬性盡量不要強制換行
某些屬性建議放在一起,比如 ngModel
和 name
,label
和 value
元素標簽盡量對齊(除單行元素外)
插值表達式盡量換行
和type
有關(guān)的屬性盡量前置
以下是根據以上規則格式化后的代碼:
我覺(jué)得模板和函數非常類(lèi)似,模板屬性就好比函數參數。如果使用 Prettier 進(jìn)行格式化,函數字符超出限制之后,所有參數默認全部折行顯示,這種方式的潛在問(wèn)題和模板屬性折行的問(wèn)題非常類(lèi)似,我覺(jué)得函數參數如果也能用 preserve-aligned
可能會(huì )更好,但是 VSCode 無(wú)法做到這一點(diǎn)。
谷歌推薦 clang-format
進(jìn)行格式化,初步試了一下,并沒(méi)有達到滿(mǎn)意的效果,可能配置文件有點(diǎn)問(wèn)題。我覺(jué)得關(guān)于函數的格式化問(wèn)題暫時(shí)可以不必深究。
代碼美化只是一種形式,它不會(huì )對邏輯產(chǎn)生任何影響,但是好的代碼格式會(huì )間接影響我們編碼的速度,甚至影響到代碼的質(zhì)量。
關(guān)鍵字: 代碼美化 開(kāi)封網(wǎng)站建設
文章連接: http://www.gostscript.com/wzjss/644.html
版權聲明:文章由 晨展科技 整理收集,來(lái)源于互聯(lián)網(wǎng)或者用戶(hù)投稿,如有侵權,請聯(lián)系我們,我們會(huì )立即刪除。如轉載請保留
晨展解決方案
晨展新聞