摘要:空格空格設置路徑格式化操作時,會自動在比如方法的右括號前,賦值語句的等號兩側等等這些位置自動加上一個空格,如果我們寫代碼時漏掉這些空格時。這樣,就方便我對別人的代碼也直接通過格式化操作來自動進行風格規范處理。
在開始講 Angular 各個核心知識點之前,想先來講講開發工具 WebStorm 的一些配置以及相應配置文件如 tslint.json 的配置。
因為我個人比較注重代碼規范、代碼風格,而對于這些規范,我只有一個觀點:一切需要依賴開發人員的主觀意識去遵守的規范都沒有多大意義。
以前做 Android 開發時會借助 AndroidStudio 來強制遵守一些規范,現在前端項目我用的是 WebStorm 開發,這兩個開發工具本質上同源,所以很多功能都差不多。
那么,這篇就來講一講,如何對 WebStorm 進行一些設置,讓它可以更好的輔助我們遵守風格規范,同時,理清一些比如 tslint.json 的配置,來讓開發工具實時檢測我們寫的代碼是否有很好的遵守規范。
Angular 項目的很多文件都是通過 Angular-CLI 工具的 ng 命令來生成的,生成時就有默認一些代碼風格,而且,WebStorm 默認也有一些代碼風格,也許有人覺得直接使用默認的風格來即可。
但對于默認的一些風格規范,我不是很贊同,比如說:
name: string = dasu
簡單的在某個類中聲明這么一個 name 變量,類型是 string,初始值為 dasu,但默認的 tslint.json 配置的代碼風格會報錯,因為它建議我們,既然已經初始化為字符串類型了,就沒有必要再去聲明變量的類型了。
對于這種默認風格,我個人并不贊同,因為個人習慣了 Java 的風格,對于變量的類型聲明已經習慣了,更何況,這個初始值有可能在未來被去掉,那么,這時候豈不是還要去加上類型說明?
所以,我個人還是比較習慣聲明變量的類型,不管有沒有對其進行初始化。
以上只是個簡單的例子,默認的一些代碼風格,我個人都不是很習慣,所以,下面列舉我的個人代碼風格,供大伙借鑒、參考。
不多,只有幾點而已,因為大多直接使用默認的代碼風格,只是默認的一些風格中,我不是很習慣的情況下,才會對其進行修改。
_
一個下劃線開頭,并添加 private
修飾符on
為前綴on
為前綴*ngFor="let item of page?.result"
這樣便于各個頁面的代碼直接復制粘貼""
雙引號,ts 中使用
單引號創建一個新的 Angular 項目時,會自動生成項目的腳手架,里面包括了各種各樣的文件,其中有一份是 tslint.json 文件,是用來給 WebStorm 實時對代碼進行 lint 檢測時的代碼風格配置。
我修改了部分默認的配置,下面給出的是所有項的配置,其中帶有注釋的配置項,就是我增加或修改原本默認的配置項,是基于我上面說的個人的一些習慣風格而進行的修改:
"rules": {
"arrow-return-shorthand": true,
"adjacent-overload-signatures": true, // override 函數是否集中放置 (新增)
"callable-types": true,
"class-name": true,
"comment-format": [
true,
"check-space"
],
"curly": true,
"deprecation": {
"severity": "warn"
},
"eofline": false, // 文件末尾是否需要空新行 (默認 true)
"encoding": true, // 文件編碼是否默認 UTF-8 (新增)
"forin": true,
"import-blacklist": [
true,
"rxjs/Rx"
],
"import-spacing": true,
"indent": [
true,
"spaces"
],
"interface-over-type-literal": true,
"label-position": true,
"max-line-length": [
true,
240 // 默認140,我屏幕挺大的,所以并不反感某一行代碼過長,相反,很多代碼因為自動換行后,我個人感覺更不習慣,還不如我手動來選擇從某個地方換行
],
"member-access": false,
"member-ordering": [
true,
{
"order": [
"static-field",
"instance-field",
"static-method",
"instance-method"
]
}
],
"no-arg": true,
"no-bitwise": true,
"no-console": [
true,
"debug",
"info",
"time",
"timeEnd",
"trace"
],
"no-construct": true,
"no-consecutive-blank-lines": [ // 空白行最多幾行 (新增)
true,
3
],
"no-debugger": false,
"no-duplicate-super": true,
"no-duplicate-switch-case": true, // 是否禁止重復 case (新增)
"no-duplicate-imports": true, // 是否禁止重復 import (新增)
"no-duplicate-variable": [ // 是否禁止重復變量聲明 (新增)
true,
"check-parameters"
],
"no-conditional-assignment": true, // 禁止在分支條件判斷中有賦值操作 (新增)
"no-empty": false,
"no-empty-interface": true,
"no-eval": true,
"no-inferrable-types": [ // 是否禁止在有初始值的變量聲明上,增加類型聲明 (默認 true)
false,
"ignore-params"
],
"no-mergeable-namespace": true, // 是否禁止重復的命名空間 (新增)
"no-misused-new": true,
"no-non-null-assertion": true,
"no-shadowed-variable": true,
"no-string-literal": false,
"no-string-throw": true,
"no-switch-case-fall-through": true,
"no-trailing-whitespace": false, // 是否禁止末尾空格 (默認 true)
"no-unnecessary-initializer": true,
"no-unused-expression": false, // 是否允許無用的表達式存在 (默認 true)
"no-unused-variable": false, // 是否允許無用的變量存在 (新增)
"no-use-before-declare": true,
"no-unsafe-finally": true,
"no-for-in-array": true,
"no-var-keyword": true,
"object-literal-sort-keys": false,
"one-line": [
true,
"check-open-brace",
"check-catch",
"check-else",
"check-whitespace"
],
"prefer-const": false, // 不強制使用 const,允許使用 let
"quotemark": [ // 引號設置,ts 中單引號
true,
"single",
"jsx-double",
"avoid-escape",
"avoid-template"
],
"radix": true,
"semicolon": [
true,
"always",
"ignore-interfaces"
],
"space-within-parens": [
true,
0
],
"triple-equals": [
true,
"allow-null-check"
],
"typedef-whitespace": [
true,
{
"call-signature": "nospace",
"index-signature": "nospace",
"parameter": "nospace",
"property-declaration": "nospace",
"variable-declaration": "nospace"
}
],
"unified-signatures": true,
"variable-name": false,
"whitespace": [
true,
"check-branch",
"check-decl",
"check-operator",
"check-separator",
"check-type"
],
"no-output-on-prefix": true,
"use-input-property-decorator": true,
"use-output-property-decorator": true,
"use-host-property-decorator": true,
"no-input-rename": true,
"no-output-rename": true,
"use-life-cycle-interface": true,
"use-pipe-transform-interface": true,
"component-class-suffix": true,
"directive-class-suffix": true
}
tslint.json 文件只是用來在執行 ng lint
命令,或者代碼編程過程中,開發工具實時檢測,當檢測到不符合風格規范的代碼時,進行報錯處理。
雖然可以在執行 ng lint --fix
時添加 --fix
參數來自動修正一些風格錯誤,但這種方式很耗時,而是代碼編寫過程中,也沒法應用。
所以,可以借助 Webstorm 的一些配置,一些小技巧,來進行代碼的格式化操作,讓開發工具自動幫我們將代碼整理成符合規范的風格。
下面介紹的這些配置項,都是為代碼的格式化操作(快捷鍵:Ctrl + Alt + L
)服務的,意思也就是說,當我們為當前文件進行代碼格式化操作時,WebStorm 就會自動按照我們的這些配置項來自動整理代碼,將代碼整理成遵循規范的風格。
設置路徑:Settings -> Editor -> Code Style -> TypeScript -> Punctuation
這里配置項很少,就三個,分別是配置分號,引號和逗號。
;
分號,且格式化時是否對舊代碼(已經過格式化的代碼)進行處理。第二行用來配置,代碼中是使用 單引號,還是
""
雙引號(默認是雙引號),且格式化時是否對舊代碼(已經過格式化的代碼)進行處理。
第三行用來配置是否需要保留,還是去掉數組或對象屬性列表中,最后一項末尾的逗號。
我的代碼風格是 HTML 中使用 ""
雙引號,TypeScript 中使用 單引號,但使用工具自動生成 ts 文件時,引號默認是雙引號,或者某些時候某些因素下,代碼中出現一些雙引號,這時候,通過修改這個配置,在每次格式化代碼時,就都會自動將雙引號轉成單引號,方便、高效。
設置路徑:Settings -> Editor -> Code Style -> TypeScript -> Spaces
格式化操作時,會自動在比如方法的 {
右括號前,賦值語句的 =
等號兩側等等這些位置自動加上一個空格,如果我們寫代碼時漏掉這些空格時。
這個功能其實是根據這里的配置項來決定的,這里面默認勾選了很多,基本符合常見的風格規范:
對于空格,我沒有改掉默認格式化時空格風格,只是增加了幾種場景也需要自動進行空格處理,分別是:
導入語句 {}
距離內容之間增加一個空格,默認是沒有的,如:
這兩個是對象內部的空格處理,默認也是沒有的,如:
設置路徑:Settings -> Editor -> Code Style -> TypeScript -> Wrapping and Braces
這里是設置一些對齊或者換行策略:
上面三個是用來設置方法鏈時,代碼的整理,默認不做處理,可以改成格式化時,自動將每層的方法調用進行換行,并且對齊處理,個人建議。
這個是設置,即使 if 代碼塊內只有簡單的一行代碼,也要自動為其加上大括號處理,默認是不做處理。
這個是用來設置 ? :
運算符的處理,上面的設置意思是,當代碼過長時,自動將 ?
和 :
的代碼換行,并對其處理,默認是不做處理。
這個是用來設置數組的處理,以上配置的意思是,當數組過長時,自動將每一項進行換行并對其處理,[]
多帶帶占據一行:
[圖片上傳失敗...(image-e2d886-1553268791353)]
對于 Angular 中的 @NgModel 的文件來說,經常會有這種風格需要,所以就直接這么配置了。
這個是用來設置變量或者對象的屬性列表的賦值語句的對齊模式,如:
同理,也可以設置 CSS 的樣式屬性的對齊方式:
以上,只是我的個人風格習慣,大體上,我都直接按照默認的風格規范來遵守,但在個把一些項上,個人有不同的看法和習慣,所以修改掉了默認的風格配置。
另外,我比較習慣使用格式化代碼操作,而且一個項目中,代碼全是我自己寫的可能性也很小,別人寫的代碼或多或少都存在一些風格規范問題,也沒辦法強制性要求他人必須遵守,所以,就瞎折騰了下 WebStorm 的相關配置。
這樣,就方便我對別人的代碼也直接通過格式化操作來自動進行風格規范處理。
大家好,我是 dasu,歡迎關注我的公眾號(dasuAndroidTv),公眾號中有我的聯系方式,歡迎有事沒事來嘮嗑一下,如果你覺得本篇內容有幫助到你,可以轉載但記得要關注,要標明原文哦,謝謝支持~
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/1070.html
摘要:整個代碼檢查和格式化流程應該規范為如下步驟使用并且嘗試自動修復所有問題有提示,可以進行修復,按照配置文件來進行修復。參考文檔如何花分鐘解決產生的各種錯誤的記憶現場本文轉載自我的更新版梳理前端開發使用和來檢查和格式化代碼問題 更新版,之前的版本可以看這里:梳理前端開發使用eslint和prettier來檢查和格式化代碼問題 一、問題痛點 在團隊的項目開發過程中,代碼維護所占的時間比重...
摘要:項目編碼規范化工具工具代碼校驗工具,讓代碼更一致和避免。在配置文件到項可對單條規則一一進行改寫。以下以項目需校驗文件為例參考鏈接一步一步,統一項目中的編碼規范 Web 項目編碼規范化工具 工具 ESLint The pluggable linting utility for JavaScript and JSX 代碼校驗工具(linting utility),讓代碼更一致和避免 bug...
摘要:打造個人團隊適用的開源項目規范是一個用來優化托管在上的多代碼庫的工作流的一個管理工具可以讓你在主項目下管理多個子項目,從而解決了多個包互相依賴,且發布時需要手動維護多個包的問題。 打造個人or團隊適用的開源項目規范 lerna Lerna 是一個用來優化托管在gitnpm上的多package代碼庫的工作流的一個管理工具,可以讓你在主項目下管理多個子項目,從而解決了多個包互相依賴,且發布...
閱讀 713·2023-04-25 19:43
閱讀 3907·2021-11-30 14:52
閱讀 3784·2021-11-30 14:52
閱讀 3852·2021-11-29 11:00
閱讀 3783·2021-11-29 11:00
閱讀 3869·2021-11-29 11:00
閱讀 3557·2021-11-29 11:00
閱讀 6105·2021-11-29 11:00