資訊專欄INFORMATION COLUMN
摘要：如果編輯器在編碼時實時給出反饋，對開發(fā)者個人而言才是最高效的，在提交時做強制檢查只是從團隊的視角保證編碼風格的規(guī)范性和一致性。
工欲善其事必先利其器，軟件工程師每天打交道最多的可能就是編輯器了。入行幾年來，先后折騰過的編輯器有 EditPlus、UltraEdit、Visual Studio、EClipse、WebStorm、Vim、SublimeText、Atom、VSCode，現(xiàn)在仍高頻使用的就是 VSCode 和 Vim 了。實際上我在 VSCode 里面安裝了 Vim 插件，用 Vim 的按鍵模式編碼，因為自從發(fā)現(xiàn)雙手不離鍵盤帶來的效率提升之后，就盡可能的不去摸鼠標。
折騰過 Atom 的我，首次試用 VSCode 就有種 Vim 的輕量感，試用之后果斷棄坑 Atom。Atom 之前，我還使用過 SublimeText，但它在保存文件時會不時彈出購買授權的彈窗，實在是令人煩惱。
每每上手新的編輯器，我都會根據自己的開發(fā)習慣把它調較到理想狀態(tài)，加上熟悉編輯器各種特性，這個過程通常需要幾周的時間。接下來，我就從外觀配置、風格檢查、編碼效率、功能增強等 4 方面來侃侃怎么配置 VSCode 來提高工作幸福感。
外觀配置外觀是最先考慮的部分，從配置的角度，無非是配色、圖標、字體等，俗話說蘿卜白菜各有所愛，我目前的配色、圖標、字體從下圖基本都能看出來，供大家參考：
配色：Solarized Dark，VSCode 已經內置，使用了至少 5 年以上的主題，Vim 下的配置完全相同；
圖標：VSCode Great Icons，給不同類型的文件配置不同的圖標，非常直觀；
字體：Fira Code，自從發(fā)現(xiàn)并開始使用 Fira Code，我就再也沒多看自其它字體一眼，字體如果比較優(yōu)雅，尤其是對數學運算符的處理，寫代碼時你真的會感覺在寫詩，哈哈，F(xiàn)ira Code 的安裝過程稍微復雜點，但是效果絕對是值當的；
配色、圖標、字體以及其他外觀配置項具體如下（注意，如果不安裝上述插件，部分配置項如果直接使用是無效的）：
{
"editor.cursorStyle": "block",
"editor.fontFamily": "Fira Code",
"editor.fontLigatures": true,
"editor.fontSize": 16,
"editor.lineHeight": 24,
"editor.lineNumbers": "on",
"editor.minimap.enabled": false,
"editor.renderIndentGuides": false,
"editor.rulers": [120],
"workbench.colorTheme": "Solarized Dark",
"workbench.iconTheme": "vscode-great-icons"
}
風格檢查
之前我寫過一篇在 Git 提交環(huán)節(jié)保障代碼風格的文章：《使用 husky 和 lint-staged 打造超溜的代碼檢查工作流》。如果編輯器在編碼時實時給出反饋，對開發(fā)者個人而言才是最高效的，在提交時做強制檢查只是從團隊的視角保證編碼風格的規(guī)范性和一致性。前端工程師會書寫的代碼無非是：HTML、CSS、Javascript、Markdown、TypeScript、JSON，對應的 Lint 工具就顯而易見：
ESLint：插件式架構，有多種主流的編碼風格規(guī)則集可供選擇，典型的有 Airbnb、Google 等，你甚至可以攢個自己的，按下不表；
StyleLint，同樣插件式架構的樣式檢查工具，不過我在配置其檢查 react-native 中 styled-components 組件樣式時確實費了不小的功夫，可以多帶帶寫篇文章了；
TSLint：TypeScript 目前不是我的主要編程語言，但也早早的準備好了；
MarkdownLint：Markdown 如果不合法，可能在某些場合導致解析器異常，因為 Markdown 有好幾套標準，在不同標準間部分語法支持可能是不兼容的；
除上面列的 Lint 工具之外，非常值得擁有的還有 EditorConfig 插件，幾乎所有主流 IDE 都有支持，我們可以通過簡單的配置文件在不同團隊成員、不同 IDE、不同平臺下約定好文件的縮進方式、編碼格式，避免出現(xiàn)混亂，下面是我常用的配置：
[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = false
insert_final_newline = true
indent_style = space
indent_size = 2
[{*.yml,*.json}]
indent_style = space
indent_size = 2
有了風格檢查，自然就會產生按配置好的風格規(guī)則做文件格式化的需求，格式化的工具試用了好多，現(xiàn)在還在用的如下：
Prettier，實際上已經是代碼格式化的工具標準，支持格式化幾乎所有的前端代碼，并且類似于 EditorConfig 支持用文件來配置格式規(guī)則；
Vetur，格式化 .vue 文件，包括里面的 CSS、JS，至于模板即 HTML 部分，官方維護者說沒有比較好的工具支持，默認是不格式化的；
編碼效率說到編碼效率，連續(xù)六年幾乎每天都編碼的我目前最大的感受是：擊鍵的速度越來越跟不上思維的速度，這種情況下，就需要在編碼時設置適當的快捷鍵，組合使用智能建議、代碼片段、自動補全來達到速度的最大化。
VSCode 內置的智能建議已經非常強大，不過我對默認的配置做了如下修改，以達到類似于在 Vim 中那樣在任何地方都啟用智能提示（尤其是注釋和字符串里面）：
{
"editor.quickSuggestions": {
"other": true,
"comments": true,
"strings": true
},
}
接下來，重點說說代碼片段和自動補全兩個效率提升利器。
代碼片段英文叫做 Snippets，市面上主流的編輯器也都支持，其基本思想就是把常見的代碼模式抽出來，通過 2~3 個鍵就能展開 N 行代碼，代碼片段的積累一方面是根據個人習慣，另一方面是學習社區(qū)里面積累出來的好的編碼模式，如果覺得不適合你，可以改（找個現(xiàn)有的插件依葫蘆畫瓢），我常用的代碼片段插件如下：
HTML Snippets，各種 HTML 標簽片段，如果你 Emmet 玩的熟，完全可以忽略這個；
Javascript (ES6) Code Snippets，常用的類聲明、ES 模塊聲明、CMD 模塊導入等，支持的縮寫不下 20 種；
Javascript Patterns Snippets，常見的編碼模式，比如 IIFE；
自動補全自動補全本質上和代碼片段類似，不過是在特殊場合下以你的鍵入做為啟發(fā)式信息提供最有可能要輸入的建議，我常用的自動補全工具有：
Auto Close Tag，適用于 JSX、Vue、HTML，在打開標簽并且鍵入 的時候，能自動補全要閉合的標簽；
Auto Rename Tag，適用于 JSX、Vue、HTML，在修改標簽名時，能在你修改開始（結束）標簽的時候修改對應的結束（開始）標簽，幫你減少 50% 的擊鍵；
Path Intellisense，文件路徑補全，在你用任何方式引入文件系統(tǒng)中的路徑時提供智能提示和自動完成；
NPM Intellisense，NPM 依賴補全，在你引入任何 node_modules 里面的依賴包時提供智能提示和自動完成；
IntelliSense for CSS class names，CSS 類名補全，會自動掃描整個項目里面的 CSS 類名并在你輸入類名時做智能提示；
Emmet，以前叫做 Zen Coding，我發(fā)現(xiàn)后，也是愛不釋手，可以把類 CSS 選擇符的字符串展開成 HTML 標簽，VSCode 已經內置，官方介紹文檔參見，你需要做的就是熟悉他的語法，并勤加練習；
當然，如果你還用 VSCode 編寫其他語言的代碼，比如 PHP，就去市場上搜索 “PHP Intellisense” 好了。
功能增強在效率提升方面除了上面的代碼片段、自動補全之外，我還安裝了下面幾個插件，方便快速的瀏覽和理解代碼，并且在不同項目之間切換。
Color Highlight，識別代碼中的顏色，包括各種顏色格式；
Bracket Pair Colorizer，識別代碼中的各種括號，并且標記上不同的顏色，方便你掃視到匹配的括號，在括號使用非常多的情況下能環(huán)節(jié)眼部壓力，編輯器快捷鍵固然好用，但是在臨近嵌套多的情況下卻有些力不從心；
Project Manager，項目管理，讓我們方便的在命令面板中切換項目文件夾，當然，你也可以直接打開包含多個項目的父級文件夾，但這樣可能會讓 VSCode 變慢；
結語說了這么多，相信讀到這里的你也期望用工具來提高自己的效率。
提高效率有沒有法門？是有的，簡單的事情重復化，重復的事情標準化，標準的事情自動化，發(fā)現(xiàn)一個痛點，用插件解決一個痛點，你的效率自然就上來了。
你都用了哪些插件呢？歡迎留言交流！
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/89740.html
摘要：如果編輯器在編碼時實時給出反饋，對開發(fā)者個人而言才是最高效的，在提交時做強制檢查只是從團隊的視角保證編碼風格的規(guī)范性和一致性。 工欲善其事必先利其器，軟件工程師每天打交道最多的可能就是編輯器了。入行幾年來，先后折騰過的編輯器有 EditPlus、UltraEdit、Visual Studio、EClipse、WebStorm、Vim、SublimeText、Atom、VSCode，現(xiàn)在...
摘要：做個記錄，上菜了如何打開配置這里以為例，其他編輯器大概也差不多。時間相關當前年份當前年份的后兩位格式化為兩位數字的當前月份，如當前月份的全稱，如當前月份的簡稱，如當天月份第幾天當天周幾，如當天周幾的簡稱，如當前小時小時制當前分鐘當前秒數。 為什么談到Snippet 今天下午在用vscode做小程序的時候，發(fā)現(xiàn)很不方便，因為商店里提供的代碼片段極為有限，而且平時幾乎每天都需要用到代碼片段...
摘要：做個記錄，上菜了如何打開配置這里以為例，其他編輯器大概也差不多。時間相關當前年份當前年份的后兩位格式化為兩位數字的當前月份，如當前月份的全稱，如當前月份的簡稱，如當天月份第幾天當天周幾，如當天周幾的簡稱，如當前小時小時制當前分鐘當前秒數。 為什么談到Snippet 今天下午在用vscode做小程序的時候，發(fā)現(xiàn)很不方便，因為商店里提供的代碼片段極為有限，而且平時幾乎每天都需要用到代碼片段...
閱讀 2524·2023-04-25 17:27
閱讀 1835·2019-08-30 15:54
閱讀 2377·2019-08-30 13:06
閱讀 2990·2019-08-30 11:04
閱讀 757·2019-08-29 15:30
閱讀 737·2019-08-29 15:16
閱讀 1740·2019-08-26 10:10
閱讀 3612·2019-08-23 17:02
