摘要:但是,有條原則應該是對的少數服從多數用工具統一風格。我曾經以為,程序員有自己獨特的代碼風格挺好的。業界有一些流行的代碼風格,比如和。你也可以使用來統一風格。比如,的配置,只能統一示例的代碼風格,而不能統一后面兩者。相比于代碼風格,我更推薦。
譯者按: 關于代碼風格,不同的人有不同的偏好,其實并沒有什么絕對的對錯。但是,有 2 條原則應該是對的: 少數服從多數;用工具統一風格。
原文: Why robots should format our code for us
譯者: Fundebug
為了保證可讀性,本文采用意譯而非直譯。另外,本文版權歸原作者所有,翻譯僅用于學習。
我曾經以為,程序員有自己獨特的代碼風格挺好的。因為,一個成熟的程序員應該清楚,好的代碼應該是怎樣的。
我的大學教授告訴我,他的學生在用我的代碼,因為我的代碼風格不一樣。我想了一下,也許是因為我的代碼至少是有風格的,而其他人的代碼一團糟。
一些示例 示例 1:讀了The Programmers’ Stone之后,我把大括號這樣寫:
if (food === "pizza") { alert("Pizza ;-)"); } else { alert("Not pizza ;-("); }
但是,我意識到在前端社區里,也許只有我一個人這樣寫的。而其他人都是這樣寫的:
if (food === "pizza") { alert("Pizza ;-)"); } else { alert("Not pizza ;-("); }
或者這樣:
if (food === "pizza") { alert("Pizza ;-)"); } else { alert("Not pizza ;-("); }
于是,我改變了風格,采用了最后一種寫法。
示例 2將多個方法鏈接起來時,我喜歡這樣寫:
function foo(items) { return items .filter(item => item.checked) .map(item => item.value) ; }示例 3
讀了Why you should enforce Dangling Commas for Multiline Statements,我意識到了trailing commas寫法更加易于重構:
const food = [ "pizza", "burger", "pasta", ]
但是,這種寫法非常少見。我審查過的代碼中,沒人這樣寫。于是,我只能放棄這種寫法,向現實世界低頭。
示例 4我還有一個不合群的習慣。在行尾寫代碼注釋之前,我習慣敲 2 個空格:
const volume = 200; // ml
我覺得這樣寫好看些。但是,這會導致代碼不一致,因為其他人只敲一個空格。
JavaScript 開發者是怎樣做的很遺憾,JavaScript 沒有官方的代碼風格。業界有一些流行的代碼風格,比如Airbnb和Standard。使用它們的話,團隊成員之間的代碼會更易讀。
你也可以使用ESLint 來統一風格。但是它并不能保證代碼 100%一致。比如,ESLint 的 Airbnb 配置,只能統一示例 1的代碼風格,而不能統一后面兩者。
JavaScript 開發者應該怎么做?有一些語言有非常嚴格的代碼風格,并且有工具可以用于統一風格。因此,開發者不需要浪費時間去爭論代碼風格的優劣。例如,Reason 語言的Refmt,和 Rust 語言的Rustfmt。
現在,JavaScript 終于有了一個解決方案。有一個新工具,叫做Prettier,它運用自身的規則將你的的代碼重新格式化。無論你之前的代碼風格是怎樣。
我們不妨試用一下 Prettier。
輸入代碼是這樣的:
if (food === "pizza") { alert("Pizza ;-)"); } else { alert("Not pizza ;-("); } function foo(items) { return items .filter(item => item.checked) .map(item => item.value) ; } const food = [ "pizza", "burger", "pasta", ]
Prettier 處理之后的代碼是這樣的:
if (food === "pizza") { alert("Pizza ;-)"); } else { alert("Not pizza ;-("); } function foo(items) { return items.filter(item => item.checked).map(item => item.value); } const food = ["pizza", "burger", "pasta"];
也許,你并不喜歡這種風格。比如,我不喜歡 else 放在大括號后面,也不喜歡把鏈式方法全部寫在同一行。但是,我發現使用Prettier有很多益處:
幾乎不需要做決定,因為 ?Prettier 的配置選項很少。
團隊成員不需要為規則去爭論。
開源代碼開發者不需要去學習項目的代碼風格。
不需要去修復 ESLint 報告的風格問題。
保存文件的時候可以自動統一風格。
結論Prettier 已經被一些非常流行的項目比如 React 和 Babel 采用了。對于我自己的項目,我已經開始從自己的個性化風格全部轉為 Prettier 風格。相比于 Airbnb 代碼風格,我更推薦 Prettier。
剛開始,我會覺得 Prettier 風格非常差。但是,當我發現自己需要手動去調整代碼風格時,我意識到 Prettier 真的非常好用。
Prettier 可以在保存文件的時候可以自動統一風格:
感興趣的話,可以按照這個教程配置 Prettier。
關于FundebugFundebug專注于JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線,Fundebug累計處理了10億+錯誤事件,付費客戶有Google、360、金山軟件、百姓網等眾多品牌企業。歡迎大家免費試用!
版權聲明轉載時請注明作者Fundebug以及本文地址:
https://blog.fundebug.com/2017/10/23/format-code-use-Prettier/
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/102775.html
摘要:由于本身不能個性化配置,有時可能會引起不適,但是至少保證團隊成員可以輕易統一代碼風格。就是將多于一個字母的合成一個字形。自從年雙十一正式上線,累計處理了億錯誤事件,得到了金山軟件等眾多知名用戶的認可。 譯者按: IDE是生產力的保證! 原文:Visual Studio Code Settings and Extensions for Faster JavaScript Develop...
摘要:官網地址推薦指數顆星推薦理由自動化部署和集成部署的好工具,操作簡單,顯示友好,具備多種插件,應有盡有,支持多類型語言的項目集成和部署。官網地址如果你有其他好用的工具,不妨也分享一下原博客鏈接前端開發團隊的工具鏈 匯集前端開發團隊中經常使用的好工具,分享給大家! 注:都是開源工具 showImg(https://segmentfault.com/img/remote/1460000019...
摘要:整個代碼檢查和格式化流程應該規范為如下步驟使用并且嘗試自動修復所有問題有提示,可以進行修復,按照配置文件來進行修復。參考文檔如何花分鐘解決產生的各種錯誤的記憶現場本文轉載自我的更新版梳理前端開發使用和來檢查和格式化代碼問題 更新版,之前的版本可以看這里:梳理前端開發使用eslint和prettier來檢查和格式化代碼問題 一、問題痛點 在團隊的項目開發過程中,代碼維護所占的時間比重...
摘要:但是關于代碼風格,我們很難區分誰對誰錯,不同的人有不同偏好,唯有強制要求才能規避爭論。所以,團隊關于代碼風格必須遵循兩個基本原則少數服從多數用工具統一風格。本文將介紹,如何使用來統一我們的前端代碼風格。 加分號還是不加分號?tab還是空格?你還在為代碼風格與同事爭論得面紅耳赤嗎? 正文之前,先看個段子放松一下: 去死吧!你這個異教徒! 想起自己剛入行的時候,從svn上把代碼checko...
摘要:忍無可忍只能拔槍相見了。而只關心格式化文件最大長度混合標簽和空格引用樣式等??梢?,代碼格式統一的問題,交給再合適不過了。和配合使用,風味更佳。我的配置文件如下到此,安裝完畢,使用就可格式化代碼。兩者配合才能使項目代碼優雅健壯 試想一個多人開發的項目,每次同步代碼,看到各個風格迥異,換行空格混亂,4格,2格縮進交替上演的代碼文件,分分鐘逼死強迫癥啊。忍無可忍只能拔槍相見了~~。統一的代碼...
閱讀 1709·2021-11-18 10:02
閱讀 2222·2021-11-15 11:38
閱讀 2671·2019-08-30 15:52
閱讀 2195·2019-08-29 14:04
閱讀 3235·2019-08-29 12:29
閱讀 2090·2019-08-26 11:44
閱讀 997·2019-08-26 10:28
閱讀 836·2019-08-23 18:37