Redmi Pad評測：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍牙耳機到筆記本電腦，紅米不知不覺之間也已經形成了自己頗有競爭力的產品體系，在中端和次旗艦市場上甚至要比小米新機的表現來得更好，正所謂“大丈夫生居
大家好，我卡頌。
配置過代碼格式化的同學一定糾結過如下問題：Eslint和Prettier都能格式化代碼風格，是單用Eslint，還是兩個一起用呢？
從今以后，你再也不用糾結這個問題，因為Eslint團隊已經妥協了 —— 根據官方博客[1]所說，從v8.53.0起，Eslint中「代碼風格相關規則」將被棄用。
有意思的是，造成上述局面的原因并不是技術問題導致的，更多是市場行為。
本文讓我們聊聊事情的來龍去脈。
在2013年之前，前端工程師通常使用JSLint或JSHint作為「代碼檢查器」，用以檢測：
比如：應該避免使用 eval()，應該使用===而不是==...
比如：未定義的變量、類型轉換的問題...
其中，JSLint基于內部實現的JS解析器，對生成的token流（詞法單元流）進行分析，檢查代碼語法。
JSHint是從JSLint派生出來的，他們工作原理類似，但JSHint更靈活 —— 他提供了.jshintrc配置文件方便開發者自定義規則。
上述兩個工具都能檢查代碼，但由于實現原理的限制，沒法進行復雜的規則檢查。同時，他們對「代碼風格」的檢查也較少。
在這一時期，「代碼風格檢查」（比如：縮進、行長度、引號類型、是否在語句末尾使用分號...）主要交給JSCS。
2013年，Eslint問世。他將代碼解析為AST并分析：
所以，Eslint不僅可以進行更復雜的規則校驗，還能讓開發者以插件的形式自己編寫規則。
所以，Eslint不僅能對代碼風格提出建議，還能自動修復「不符合規范的風格」。
更先進的功能，再加上作者身份加持（作者是紅寶書作者），使得Eslint逐漸淘汰了上述競品。
雖然Eslint提供了大量規則，但并不是所有開發者都想配置一套自己的規則集。
慢慢的，一些「Eslint規則集的最佳實踐」被提出（比如Airbnb規則[2]、standard規則[3]）。
開發者通常會在這些規則集的基礎上再做些個性化修改，組成項目的lint規則集。
這些規則集中，通常包含三類規則：
其中「代碼風格檢查」通常是非常主觀的。如果團隊成員的「代碼風格檢查規則」配置不一樣，很影響提交時git diff的可讀性。
為了強制規范「代碼風格檢查」，Prettier出現了。這是一款「固執己見」的代碼風格格式化工具，他集成了一套代碼風格，并且可配置程度不高。
「可配置程度不高」是一把雙刃劍，一方面，他能強制規范團隊成員的代碼風格。
但另一方面，如果想對代碼風格做些個性化設置，Prettier很有可能不支持。
舉個例子（來自為什么我不使用 Prettier中的例子），Prettier中通過printWidth屬性配置「一行可以顯示的字符數」，超過就會折行。
有時候我們并不需要「超過某個字符數就折行」，因為在Git Diff時，折行會破壞Diff信息的可讀性：
然而遺憾的是，Prettier并沒有提供配置關閉這一行為。
基于上述原因，出現了兩種解決方案：
其中Eslint負責代碼質量、錯誤檢查，Prettier負責代碼風格檢查。優點是能夠滿足代碼質量、風格檢查。缺點是：
使用「代碼風格相關規則的集合」，比如@stylistic/eslint-plugin-js[4]管理代碼風格。再使用其他規則管理代碼質量。
這種方式優點明顯 —— 可配置性高，且配置簡單（只需要配置Eslint）。
顯然，方案2是優于方案1的。既然如此，Eslint團隊為什么要棄用所有「代碼風格相關規則」呢？
設想一下，每當出現新的語言特性，與該特性相關的規則包括：
顯然前兩者的優先級、重要性都高于第三者。如果說，在Eslint成長初期，為了收割JSCS的用戶，Eslint必須實現所有「JSCS支持的代碼風格規則」，此時實現各種代碼風格規則是必要的。
但今時今日，Eslint早已成為JS領域「代碼檢查器」的老大，不需要再為了市場份額努力滿足社區的一切需要。況且，有些時候，考慮「規則沖突」以及「一致性」，有些需求甚至無法滿足。
最理想的情況，所有核心規則都能很好地相互配合，這意味著沒有兩個規則應該標記同一個問題，也不會有任何兩個核心規則給出相互沖突的建議。
當核心規則少于30條時，這很容易。但對于越來越多的規則，這很難做到。
ESLint規則之間是無法互相訪問的。這意味著我們會遇到無法正確修復錯誤的問題，因為信息可能位于另一個規則中。
舉個例子，如果自動修復需要添加新的代碼行，就需要知道文件是如何縮進的，以便應用正確的修復。但是，規則indent控制ESLint的縮進，這意味著其他規則需要在不縮進的情況下應用修復，然后相信indent規則將在后續傳遞中修復縮進。
ESLint從v8.53.0起，將棄用「代碼風格相關規則」。這么做主要是因為繼續維護「代碼風格相關規則」對核心團隊來說，投入產出比太低。
試想一下，核心團隊花費大力氣解決問題（規則沖突、一致性問題），推出新的「代碼風格規則」，開發者會感謝Eslint核心團隊的付出么？
不會的，這些「代碼風格規則」會被集成到規則集中，并被冠以「某種開發理念」兜售給開發者（比如Airbnb規范）。
實際收獲名利的是站在臺前的「宣傳開發理念的團隊」，而背后辛苦干活的Eslint核心團隊往往被忽略了，換你你樂意么？
[1]官方博客:https://eslint.org/blog/2023/10/deprecating-formatting-rules/。
[2]Airbnb規則:https://airbnb.io/javascript/。
[3]standard規則:https://standardjs.com/。
[4]@stylistic/eslint-plugin-js:https://www.npmjs.com/package/@stylistic/eslint-plugin-js。
本文鏈接：http://www.tebozhan.com/showinfo-26-16038-0.htmlEslint團隊終于妥協了...
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Quarkus vs. Spring Boot：Java開發的革命與傳統之爭
下一篇： 通過實例理解Web應用用戶密碼存儲方案
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號