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