工欲善其事,必先利其器。軟件開發者不只須要提高本身的軟實力,也須要找到趁手的工具。今天要介紹的主角是 Visual Studio Code,簡稱 VSCode,來自微軟。前端
VSCode 是一款代碼編輯器,核心用戶羣就是軟件開發者。固然也有人把 VSCode 稱爲輕量 IDE,彷佛也沒什麼錯。怎麼說呢,來看一張經典截圖。這個截圖來自 2017 SpringOne 大會上,Erich Gamma 的主題演講。java
∟ Erich Gamma 介紹 VSCode 定位偏向於編輯器node
Erich Gamma 介紹 VSCode 的定位時表示,VSCode 的定位是一個編輯器,可是主要是針對程序員,因此它要能理解代碼,並提供必定的調試能力。git
普通的編輯器能力你們都理解,無非就是平常編輯功能。而代碼理解能力則須要根據用戶當前編輯的內容對用戶進行提示(好比函數參數提示),以及幫助用戶快速完成代碼編碼(如自動完成),甚至能提供一些代碼靜態檢查和重構的功能。爲此 VSCode 與 TypeScript 聯合研發了 LSP(Lanuage Service Protocol),基於 LSP,任何語言均可以實現符合協議的語言服務,任何編輯器均可以經過 LSP 使用這些服務爲用戶提供基於語言理解的編輯體驗。程序員
一款好用的編輯器,不只須要有實用的功能,優雅的界面,舒服的操做體驗,還應該具備良好的生態和活躍的社區支持。我之前曾經看到不少人以一己之力開發出來的初見鋒芒的編輯器都只是曇花一現,很快就消失了。若是他們有良好的生態和社區支持,必定會發展得更好。有一篇博文叫《VS Code爲何能這麼牛?》從產品和技術的角度講解了 VSCode 爲何會發展得這麼好,有興趣的朋友能夠去找找看。github
因爲VSCode 有良好的生態和強大的社區支持,因此有不少插件能夠加強其編輯能力,這些插件在 https://marketplace.visualstudio.com/VSCode 能夠找到。若是以爲這個地址很差記,能夠簡單的記住 VSCode 的主頁 https://code.viusalstudio.com/ ,進去以後在上方「Extensions」處進入。typescript
下面就是我在平常工做中精挑細選的一些插件,推薦給你們。不過首先聲明,插件的使用跟我的的工做環境有很大關係,我主要工做在 C#、.NET 和 JavaScript 相關技術上,對於較大型的 .NET 項目通常使用 Visual Studio。因此 VSCode 在我這裏主要起到三個方面的做用:express
.cs
, .java
, .groovy
, .json
, .md
等。由於若是源文件是以項目組織的,一般會使用專業的 IDE,好比 Visual Studio,Eclipse 等。所以,插件也是跟這些做用相關的。下面開始正式推薦插件 —— 表面上是在推薦 VSCode 的插件,實際上也是在推薦一些工具。npm
https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfigjson
在團隊協做開發時,可使用 EditorConfig (https://editorconfig.org/) 同步編輯器設置,統一開發規範。目前不少知名編輯器、IDE 都原生或經過插件支持 EditorConfig。EditorConfig 在官網上列舉支持這一標準的編輯器和IDE,看看你習慣使用的編輯器和 IDE 是否在列。
項目中使用 .editorconfig
配置文件來配置編輯選項,具體的配置說明能夠參閱官方文檔 (https://editorconfig.org/#file-format-details)。下面來看一個簡單的配置示例:
[*] # 對全部文件進行配置 charset = utf-8 # 使用 UTF-8 編碼 indent_style = space # 使用空格縮進 end_of_line = lf # 統一使用 Unix 換行符 [*.js] indent_size = 4 # JS 文件縮進爲 4 個單位(前面配置爲空格) [*.{json,xml}] indent_size = 2 # JSON 和 XML 文件縮進爲 2 個單位
因爲 EditorConfig 容許擴展,因此甚至有 IDE 爲語言定製了專門的配置項,好比 Visual Studio 2019:
[*.cs] # 空檢查相關的配置 csharp_style_throw_expression = true:suggestion csharp_style_conditional_delegate_call = true:suggestion # 甚至能夠配置在編輯器裏不提示某些警告 [*.cs] # CS1591: Missing XML comment for publicly visible type or member dotnet_diagnostic.CS1591.severity = silent
使用 EidtorConfig 後,團隊協做開發時再也不用擔憂代碼格式不統一了。因爲 EditorConfig 像 LSP 同樣有一個跨編輯器的標準,因此即便團隊成員喜歡使用不一樣的編輯器或 IDE,也能使用相同的代碼格式標準。
https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2
這個插件可使用彩色高亮匹配括號,加強代碼閱讀。來看看花裏胡哨但很實用的的括號配對:
∟ Bracket Pair Colrizer 2 的多彩匹配
此外,還能夠有一些連線來顯示括號之間的關係。注意下圖中光標在不一樣的位置時,匹配的括號和輔助連線的區別。
∟ 使用連線表示光標所在且離光標最近的一對括號
寫代碼時保持良好的縮進和簡潔的代碼是個好習慣。雖然這個插件在良好的代碼風格做用會有一些折扣,可是現在函數式代碼橫行,找到正確匹配的括號仍是蠻重要的。
https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint
ESLint 是一個 JavaScript 和 TypeScript 代碼的靜態檢查工具,能夠檢查出代碼中不符合編寫規範的地方,也能夠檢查出一些從語法上識別可能存在邏輯錯誤的地方,幾乎是前端開發的必備工具。VSCode 使用 ESLint 插件來支持編輯期間對代碼進行檢查,高亮檢查出來的問題,並對可自動修改的問題提供快速修復功能。
在使用 VSCode 開發 npm 項目的時候,該插件會自動使用 node_modues/eslint
來進行檢查。項目內使用以下命令安裝 esling:
my-project> npm install --save-dev eslint
若是是編輯項目外的 .js
或 .ts
文件,則須要使用 npm 全局安裝的 eslint
。以下安裝全局 eslint:
npm install -g eslint
若是項目內有 ESLint 配置文件(.eslintrc
、.eslintrc.json
、.eslintrc.js
等),該插件會按照這個配置來進行檢查。若是沒有,則按照全局配置進行檢查。全局配置在
%userprofile%\.eslintrc.*
~/.eslintrc.*
要特別說明的一點是,TypeScript 官方宣佈全面支持 ESLint,
原本還有一個叫 TSLint 的插件,不過其 Github 項目主頁 README 說得明白:TSLint is deprecated.
。
∟ TSLint 已聲明過時,使用 ESLint 代替
TypeScript 代碼如今由 ESLint 負責檢查,TSLint 的 typescript-eslint (https://github.com/typescript-eslint/typescript-eslint) 插件就是幹這個事情的。
Git 是現代開發經常使用的工具之一,默認安裝的 Git 提供命令行操做。Git Windows 也能夠以安裝的時候安裝一個默認的 GUI 客戶端。除此以外,Git 在 GUI Client 頁面 (https://git-scm.com/download/gui/windows) 也介紹了很多 Git 的 GUI 客戶端。不過怎麼說呢,對我來講,不收費的用不慣,用得慣的要收費。因此最後乾脆直接用 VSCode 內置的 Git 功能吧。配合插件,平常操做徹底沒問題。
這裏主要推薦兩個 Git 插件,Git Graph 和 GitLens。
Git Graph: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph
GitLens: https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens
Git Graph 就是一個漂亮的提交歷史查看工具,同時還支持在歷史提交記錄上進行一些快捷操做,好比建立分支、建立標籤、合併分支、Cherry Pick 等。不用過多介紹,直接看效果圖就能瞭解:
∟ Git Graph 很是漂亮的呈現了提交歷史
GitLens 的官方介紹很是詳細,因此這裏不用多說,只說我經常使用的兩個功能就好:
在 Compare 界面直接比較兩個分支,參與比較的能夠是本地分支,也能夠是遠程分支。
∟ GitLens 比較兩個分支
基於 Git 的代碼管理,每每須要將任務分支推到服務器以後,經過 PR 合併,再刪除任務分支。遠端雖然刪除了,但本地 origin
還保存着記錄,須要使用 git remote prune origin
命令清理。說實在的,這個命令若是沒用慣還真記不住,不過 GitLens 的 Repositories 界面,Git 庫下面的 「Remotes ⇒ orign」上右鍵,能夠直接清理 origin,免得去寫命令行的麻煩。
∟ GitLens 清理 origin
https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.todo-tree
不知道你們有沒有在代碼註釋中寫任務的習慣,好比 TODO
,NOTE
,FIXME
之類的任務標記。Todo Tree 就是一個檢索並管理這些任務標記的工具。
∟ Todo Tree
支持哪些任務標記,每種標記用什麼樣的顏色和圖標表示,均可以在用戶配置中設置:
"todo-tree.general.tags": [ // 這裏配置支持的任務標記 "TODO", "FIXME", "DEBUG", "NOTE" ], "todo-tree.highlights.customHighlight": { // 這裏配置顏色和圖標 "DEBUG": { "foreground": "#909090", "icon": "tools", "type": "text-and-comment" }, "FIXME": { "foreground": "#f33958", "icon": "bug", "type": "text-and-comment" }, "NOTE": { "foreground": "#4375cd", "icon": "pencil" }, "TODO": { "foreground": "#ffca28", "icon": "checklist" } }, "todo-tree.highlights.defaultHighlight": { // 這是默認的顏色(上面的配置匹配不到的狀況) "foreground": "#dcd079", "opacity": 50, "type": "tag" },
https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare
這個是協同開發的重量級工具。若是團隊不在一塊兒,又須要進行一些協做,這個工具就很是有用。
團隊不在一塊兒,協做基本上靠截圖、視頻和遠程協助。截圖效率低,視頻看不清,遠程運行卡……那麼這個時候就可使用 Live Share 了。主持方開始 Live Share Session 以後能夠邀請使用 Live Share 的團員加入,而後你們能夠
Visual Studio 也有 Live Share 插件。VS 和 VSCode 之間能夠共同 Share,不須要雙方使用相同的編輯器或 IDE。對於遠程協做團隊來講,這個插件真是太太太好用了!
https://marketplace.visualstudio.com/items?itemName=VisualStudioExptTeam.vscodeintellicode
你們都知道代碼提示好用, 自動完成好用。可是,基於 LSP 的這些功能畢竟是死的,配置好的,根據 SDK 無差異提示的。若是能智能一點就行了,好比當初寫 Java 程序時,IDEA 會根據類型自動推薦變量名……
那麼,你須要 IntelliCode。這款插件叫 Visual Studio IntelliCode,是由於它來源於 Visual Studio。它帶來了智能代碼提示功能,包括加強代碼提示、推薦經常使用方法、屬性等。聽說推薦信息來源於對網絡上大量代碼的大數據分析。
∟ Visual Studio IntelliCode 智能提示
圖中,打星星的就是智能提示的內容。你看,輸入 console.
彈出建議時,經常使用的方法都列在了前端,選起來快多了。
不過遺憾的是,目前 VSCode 的這款插件只支持 Python,JavaScript/TypeScript 和 Java。若是須要對 C#、C++ 等語言的支持,請使用 Visual Studio。
VSCode 插件不少,須要什麼直接去市場上找,下載量大的,投票數高的,符合要求直接拿來用。用了不順手卸載了再找下一個;用了順手發篇博文分享一下。
除了上面介紹的插件外,我還使用了不少其餘插件,由於篇幅有限,就不展開介紹了。這些插件包括(按字母序,沒給連接,直接去插件市場搜就行):
本次分享到此結束,若是朋友們知道其餘好用的插件,不妨留言/評論分享一下!
喜歡此文,點個**