Nenávidím funkce šipek

TL;DR

Funkce šipek jsou vhodné pro určitá použití, ale mají tolik variant, že je třeba je pečlivě kontrolovat, aby nenarušily čitelnost kódu.

Zatímco funkce šipek jasně mají všudypřítomný konsenzus komunity (i když ne jednomyslnou podporu!), ukazuje se, že existuje široká škála názorů na to, proč je použití => "dobré" a ne.

Konfigurovatelná pravidla linter jsou nejlepším řešením pro spory o rozmanitost a neshodu funkcí šipek.

Uvolnil jsem proper-arrows ESLint plugin s několika konfigurovatelnými pravidly pro ovládání => funkce šipky ve vaší kódové základně.

Názory jsou jako nosy...

Každý, kdo mě sleduje (tweety, knihy, kurzy atd.) velmi dlouho, ví, že mám spoustu názorů. Ve skutečnosti je to jediná věc, na kterou jsem expert -- své vlastní názory -- a nikdy s nimi nejsem bezradný!

Nehlásím se k mantře "silné názory, volně držené". „Nezastávám“ své názory, protože nevidím smysl mít nějaký názor, pokud pro něj není dostatečný důvod. Než si vytvořím názor, který bych veřejně sdílel, trávím spoustu času zkoumáním a kutilstvím a psaním a zkoušením nápadů. V tomto bodě je můj názor dosti silně zastáván, z nutnosti.

A co víc, učím na základě těchto názorů -- tisíce vývojářů v různých společnostech po celém světě -- což mi poskytuje příležitost hluboce prověřit své názory prostřednictvím nesčetných diskuzí a debat. Jsem nesmírně poctěn být v takové pozici.

To neznamená, že nemohu nebo nechci změnit své názory. Ve skutečnosti se jeden z mých nejsilněji zastávaných názorů – že typy JS a donucení jsou v JS užitečné – v poslední době posouvá do poměrně významné míry. Mám mnohem zakulacenější a prohloubenější pohled na typy JS a na to, proč mohou být užitečné nástroje založené na typu. A dokonce i můj názor na => funkce šipek, pointa tohoto článku, se vyvinula a prohloubila.

Ale jedna z věcí, které mi mnoho lidí říká, že si mě na mně váží, je, že své názory jen nevyjadřuji, tyto názory podepírám pečlivým a promyšleným uvažováním. I když lidé vehementně nesouhlasí s mými názory, často mi skládají komplimenty za to, že tyto názory alespoň s podporou vlastním.

A totéž se snažím inspirovat v ostatních prostřednictvím svého mluvení, výuky a psaní. Je mi jedno, jestli se mnou souhlasíte, jde mi pouze o to, abyste věděli, proč máte technický názor, a mohli ho seriózně obhajovat svou vlastní úvahou. Pro mě je to zdravý vztah k technologii.

Funkce šipek !=function s

Upřímně věřím, že => funkce šipky není vhodná jako univerzální náhrada za všechny (nebo dokonce většinu) function funkce ve vašem kódu JS. Opravdu je ve většině případů nepovažuji za čitelnější. A nejsem sám. Kdykoli sdílím na sociálních sítích podobný názor, často dostanu desítky "já taky!" odpovědi doplněné skóre "totálně se mýlíš!" odpovědi.

Ale nejsem tady, abych přeháněl celou debatu o => funkce šipky. Napsal jsem obsáhle o svých názorech na ně, včetně těchto částí ve svých knihách:

• "You Don't Know JS:ES6 &Beyond", Ch2, "Arrow Functions"
• "Functional-Light JavaScript", Ch2, "Funkce bez function " (a předchozí část o názvech funkcí).

Bez ohledu na vaše preference kolem => , naznačovat, že je to pouze lepší function má být jasně redukční. Je to mnohem jemnější téma než jen osobní korespondence.

Na => se vám líbí věci . Možná vás to mě překvapí abych řekl, protože se zdá, že většina lidí předpokládá, že nenávidím funkce šipek.

Já ne (nesnáším je). Myslím, že určitě existují některé důležité výhody.

Jen je bezvýhradně neschvaluji jako nové function . A v dnešní době většinu lidí nezajímají nuancované názory uprostřed. Takže protože nejsem úplně v pro-=> táboře, musím být zcela v opozičním táboře. Není pravda .

Co nesnáším, je naznačování, že jsou všeobecně čitelnější nebo že jsou objektivně lepší v podstatě ve všech případech.

Důvod, proč odmítám tento postoj, je ten, že OPRAVDU MÁM S NÁBOŽÍM JE PŘEČÍT v mnoha případech. Takže díky této perspektivě se jako vývojář cítím hloupě/méněcenně. „Něco se mnou musí být v nepořádku, protože si nemyslím, že je to čitelnější. A nejsem jediný, koho syndrom podvodníka vážně rozdmýchává taková absolutna.

A třešničkou na dortu je, když vám lidé řeknou, že jediný důvod, proč nerozumíte nebo se vám nelíbí => je to proto, že jste se je nenaučili nebo dostatečně nepoužívali. Dobře, děkuji za (shovívavou) připomínku, že je to kvůli mým neznalost a nezkušenost. SMH. Napsal jsem a přečetl doslova tisíce => funkcí. Jsem si docela jistý, že o nich vím dost na to, abych zastával své názory.

Nejsem v pro-=> tábor, ale uznávám, že někteří je opravdu preferují, oprávněně. Uvědomuji si, že někteří lidé přicházejí do JS z jazyků, které používají => a tak se cítí a čtou zcela přirozeně. Uznávám, že někteří dávají přednost jejich podobnosti s matematickým zápisem.

IMO je problematické, když někteří v těchto táborech prostě nemohou pochopit nebo se vcítit do odlišných názorů, jako by tam prostě muselo být něco špatně s nimi.

Čitelnost !=Zapisovatelnost

Také si nemyslím, že ty víte, o čem mluvíte, když mluvíte o čitelnosti kódu. Celkově je velká většina názorů na čitelnost kódu, když je rozeberete, založena na osobním postoji k preferencím v psaní stručný kód.

Když se v debatách o čitelnosti kódu odsouvám, někteří se jen hrabou v patách a odmítají podpořit svůj názor. Jiní se vzdají obav s tím, že „čitelnost je stejně jen subjektivní“.

Chatrnost této odpovědi je ohromující:před dvěma sekundami vehementně tvrdili => šipka je absolutně a objektivně čitelnější, a když ji zmáčknou, přiznají, "no, já myslím, že je to čitelnější, i když ignoranti jako ty ne.“

Hádej co? Čitelnost je subjektivní,ale ne tak úplně . Je to opravdu složité téma. A jsou někteří, kteří se zavazují formálně studovat téma čitelnosti kódu, aby se pokusili zjistit, které části jsou objektivní a které subjektivní.

Takových výzkumů jsem přečetl poměrně hodně a jsem přesvědčen, že je to dostatečně složité téma, že se to nedá zredukovat na slogan na tričku. Pokud si je chcete přečíst, doporučil bych vám, abyste si na Googlu prohledali a přečetli si vlastní.

I když sám nemám všechny odpovědi, jednou věcí, kterou jsem si jistý, je, že kód se častěji čte než píše, takže pohledy na toto téma, které nakonec pocházejí z toho, že „je jednodušší/rychlejší psát“, moc neobstojí. stojící. Co je třeba zvážit, není to, kolik času ušetříte psaním, ale jak jasně bude čtenář (budoucí vy nebo někdo jiný v týmu) schopen porozumět? A v ideálním případě mu většinou porozumí, aniž by kód přelévali hřebenem s jemnými zuby?

Jakýkoli pokus odůvodnit možnosti zápisu nepodloženými tvrzeními o výhodách čitelnosti je přinejlepším slabým argumentem a obecně nic jiného než rozptýlení.

Takže toto => zásadně odmítám je vždy a objektivně „čitelnější“.

Ale stejně nesnáším funkce šipek. Jen si myslím, že abychom je mohli efektivně využívat, musíme být disciplinovanější.

Linters ==Disciplína

Můžete se (nesprávně) domnívat, že linters vám sdělují objektivní fakta o vašem kódu. mohou to udělat, ale to není jejich primární účel.

Nástroj, který se nejlépe hodí k tomu, aby vám sdělil, zda je váš kód platný, je kompilátor (tj. jádro JS). Nástroj, který vám nejlépe sdělí, zda je váš kód „správný“ (dělá, co chcete), je vaše testovací sada.

Ale nástroj, který se nejlépe hodí k tomu, aby vám sdělil, zda je váš kód vhodný je linter. Linters je soubor pravidel o tom, jak byste měli stylizovat a strukturovat svůj kód, abyste se vyhnuli pravděpodobným problémům – podle autorů těchto pravidel založených na názoru.

K tomu slouží:aplikovat názory na váš kód.

To znamená, že je téměř jisté, že vás tyto názory někdy „urazí“. Pokud jste jako většina z nás, máte chuť na to, co děláte, a víte, že to, co děláte na tomto řádku kódu, je správné . A pak se objeví linter a řekne:"Ne, nedělej to tak."

Pokud je vaším prvním instinktem někdy nesouhlasit, pak jste jako my ostatní! Citově se připoutáváme ke svým vlastním perspektivám a schopnostem, a když nám nějaký nástroj řekne, že se mýlíme, trochu se nadechneme.

Nezlobím se na testovací sadu ani na JS engine. Všechny tyto věci vyjadřují fakta o mém kódu. Ale určitě se dokážu naštvat, když linterův názor nesouhlasí s mým.

Mám toto jedno pravidlo linter, které jsem povolil před několika týdny, protože jsem měl nekonzistenci v kódování, která mě obtěžovala při opětovném čtení kódu. Ale teď se toto pravidlo chuchvalců objevuje dvakrát nebo třikrát za hodinu a otravuje mě jako stereotypní babičku v sitcomu z 90. let. Pokaždé přemýšlím (jen na okamžik), jestli bych to pravidlo neměl prostě deaktivovat. Nechávám to zapnuté, ale k mému zklamání.

Tak proč se vystavovat tomuto trápení!? Protože nástroje linter a jejich názory jsou tím, co nám dává disciplínu. Pomáhají nám spolupracovat s ostatními.

V konečném důsledku nám pomáhají komunikovat jasněji v kódu.

Proč bychom neměli nechat každého vývojáře, aby se rozhodoval sám? Kvůli naší tendenci k citové vazbě. Zatímco jsme v zákopech pracujeme na vlastním kódu , navzdory nepřiměřenému tlaku a lhůtám jsme v nejméně důvěryhodném myšlení, abychom mohli vyslovovat takové úsudky.

Měli bychom se podrobit nástrojům, které nám pomohou udržet naši disciplínu.

Je to podobné, jako když se zastánci TDD podrobují disciplíně psaní testů nejprve ve formálním souboru kroků. Disciplína a celkový výsledek procesu jsou toho, čeho si ceníme nejvíce, když jsme dostatečně naladěni, abychom provedli tuto analýzu. Tento druh procesu nezavádíme, když je náš kód beznadějně rozbitý a nemáme ponětí proč, a pouze se uchylujeme ke zkoušení náhodných změn kódu, abychom zjistili, zda to opraví!

Ne. Pokud budeme rozumní, připouštíme, že celkově dobré nejlépe poslouží, když nastavíme rozumná pravidla a poté se budeme řídit disciplinou, abychom je dodržovali.

Konfigurovatelnost je král

Pokud se budete vědomě podrobovat tomuto máchání prstem, vy (a váš tým, pokud je to možné) budete jistě chtít něco říct, jaká pravidla musíte hrát. Svévolné a nenapadnutelné názory jsou nejhorší.

Pamatujete na časy JSLint, kdy 98 % pravidel byly pouze názory Crockforda a vy jste nástroj buď používali, nebo ne? Přímo vás v README varoval, že se urazíte a že byste to měli prostě překonat. To byla legrace, že? (Někteří z vás možná stále používají JSLint, ale myslím, že byste měli zvážit přechod na modernější nástroj!)

To je důvod, proč je ESLint v dnešní době králem linterů. Filozofie je v podstatě taková, aby bylo vše konfigurovatelné. Nechte vývojáře a týmy demokraticky rozhodnout, kterým názorům se všichni chtějí podřídit, pro jejich vlastní disciplínu a dobro.

To neznamená, že každý vývojář si vybírá svá vlastní pravidla. Účelem pravidel je přizpůsobit kód rozumnému kompromisu, „centralizovanému standardu“, který má nejlepší šanci co nejjasněji komunikovat s většinou vývojářů v týmu.

Ale žádné pravidlo není nikdy 100% dokonalé. Vždy existují výjimečné případy. To je důvod, proč možnost zakázat nebo překonfigurovat pravidlo například pomocí vloženého komentáře není jen malý detail, ale kritická funkce.

Nechcete, aby vývojář měl pouze svou vlastní místní konfiguraci ESLint, která přepíše pravidla, zatímco zadávají kód. Chcete, aby vývojář buď dodržoval zavedená pravidla (výhodně!) NEBO udělat výjimku z pravidel, která je jasná a zřejmá přímo v okamžiku, kdy se výjimka dělá.

V ideálním případě lze tuto výjimku prodiskutovat a prodiskutovat a prověřit během kontroly kódu. Možná to bylo oprávněné, možná ne. Ale alespoň to bylo zřejmé a alespoň se o tom dalo diskutovat.

Konfigurovatelnost nástrojů je způsob, jakým zajišťujeme, aby nástroje pracovaly za nás, místo abychom my pracovali pro nástroje.

Někteří preferují k nástroji přístupy založené na konvencích, kde jsou pravidla předem určena, takže nedochází k diskusím ani debatám. Vím, že to funguje pro některé vývojáře a pro některé týmy, ale nemyslím si, že je to udržitelný přístup pro zobecněné, široké použití. Nakonec nástroj, který je neflexibilní vůči měnícím se potřebám projektu a DNA vývojářů, kteří jej používají, nakonec upadne do neznáma a nakonec bude nahrazen.

Správné šipky

Plně si uvědomuji, že jsem použil slovo "správný" tady bude nacuchat nějaké peří. "Kdo je getify, aby říkal, co je správné a co ne?"

Pamatujte, že se vám nesnažím říkat, co je správné. Snažím se vás přimět, abyste přijali myšlenku, že názory na => funkce šipek jsou tak rozmanité jako všechny nuance jejich syntaxe a použití, a to, co je nakonec nejvhodnější, je nějaký soubor názorů , bez ohledu na to, jaké jsou, by měly být použitelné.

I když jsem velkým fanouškem ESLint, byl jsem zklamán nedostatkem podpory ze strany vestavěných pravidel ESLint pro ovládání různých aspektů => funkce šipky. Existuje několik vestavěných pravidel, ale frustruje mě, že se zdá, že se většinou zaměřují na povrchní stylistické detaily, jako jsou mezery.

Myslím, že existuje řada aspektů, které mohou brzdit => čitelnost funkce šipky, problémy, které jdou nad rámec toho, co může aktuální sada pravidel ESLint kontrolovat. Ptal jsem se na twitteru a z mnoha odpovědí se zdá, že na to má názor mnoho lidí.

Ultimátní linter by vám umožnil nejen konfigurovat pravidla podle vašich představ, ale vytvořit si vlastní pravidla, pokud by něco chybělo. Naštěstí ESLint přesně to podporuje!

Rozhodl jsem se tedy vytvořit plugin ESLint, který definuje další sadu pravidel kolem => funkce šipek:správné šipky .

Než o tom něco vysvětlím, dovolte mi upozornit:je to soubor pravidel, která lze zapnout nebo vypnout a nakonfigurovat podle svého uvážení. Pokud považujete byť jen jeden detail jednoho pravidla za užitečný, bylo by lepší pravidlo/plugin použít než ne.

Jsem v pořádku, když máte vlastní názory na to, co dělá => šipka funguje správně. Ve skutečnosti je to celé. Pokud máme všichni na => různé názory arrow funkce, měli bychom mít podporu nástrojů, která nám umožní vybrat a nakonfigurovat tyto různé názory.

Filozofií tohoto pluginu je, že pro každé pravidlo, když pravidlo zapnete, máte ve výchozím nastavení zapnuté všechny jeho režimy hlášení. Pravidlo ale samozřejmě můžete buď nezapnout, nebo pravidlo zapnout a poté nakonfigurovat jeho režimy, jak uznáte za vhodné. Ale nechci, abyste museli hledat pravidla/režimy, které chcete zapnout, kde jejich nejasnost brání tomu, aby byly vůbec brány v úvahu. Takže vše funguje podle pravidla.

Jedinou výjimkou je, že ve výchozím nastavení všechna pravidla ignorují triviální => funkce šipky, například () => {} , x => x , atd. Pokud chcete, aby byly kontrolovány, na základě pravidel musíte tuto kontrolu zapnout pomocí { "trivial": true } možnost.

Správná pravidla pro šipky

Jaká pravidla jsou tedy stanovena? Zde je výňatek z přehledu projektu:

• "params" :řídí definice => parametry funkce šipky, jako je zákaz nepoužívaných parametrů, zákaz krátkých/nesémantických názvů parametrů atd.
• "name" :vyžaduje => funkce šipky používat pouze na pozicích, kde obdrží odvozený název (tj. přiřazené proměnné nebo vlastnosti atd.), aby se předešlo špatné čitelnosti/laditelnosti výrazů anonymních funkcí.
• "where" :omezuje, kde ve struktuře programu => lze použít funkce šipky:jejich zákaz v nejvyšší úrovni/globálním rozsahu, vlastnosti objektu, export prohlášení atd.
• "return" :omezuje druh stručné návratové hodnoty pro => funkce šipky, jako je zákaz doslovných výstižných návratů objektu (x => ({ x }) ), zakazující stručné vracení podmíněných/ternárních výrazů (x => x ? y : z ), atd.
• "this" :vyžaduje/zakazuje => funkce šipky pomocí this odkaz v => samotná funkce šipky nebo ve vnořeném => funkce šipky. Toto pravidlo může volitelně zakázat this -obsahující => funkce šipky z globálního rozsahu.

Pamatujte, že každé pravidlo má různé režimy ke konfiguraci, takže nic z toho není všechno nebo nic. Vyberte si, co vám vyhovuje.

Jako ilustraci toho, co jsou správné šipky pravidla mohou zkontrolovat, podívejme se na "return" pravidlo, konkrétně jeho "sequence" režimu. Tento režim odkazuje na stručný návratový výraz => funkce šipky jsou sekvencí oddělenými čárkami , takto:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sekvence se obvykle používají v => Funkce šipky stručné vrátí řetězec společně s více (výrazovými) příkazy, aniž by bylo nutné použít celý { .. } tělo funkce s oddělovači a explicitní return prohlášení.

Někomu se tento styl může líbit – to je v pořádku! -- ale mnoho lidí si myslí, že upřednostňuje chytré stručné stylové kódování před čitelností, a raději by místo toho:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Všimněte si, že je to stále => funkce šipky a není to ani o tolik více znaků. Ale je jasnější, že v tomto těle funkce jsou tři samostatné příkazy.

Ještě lepší:

var fn2 = (x,y) => {
   x = 3;
   y = foo(x + 1);
   return [x,y];
};

Aby bylo jasno, správné šipky pravidla nevynucují triviální rozdíly ve stylu, jako jsou mezery/odsazení. Pokud chcete tyto požadavky vynutit, existují další (vestavěná) pravidla. správné šipky se zaměřuje na to, co považuji za podstatnější aspekty => definice funkce.

Stručné shrnutí

Vy a já se téměř jistě neshodneme na tom, co je dobré a správné => styl funkce šipky. To je dobrá a zdravá věc.

Můj cíl je zde dvojí:

1. Přesvědčit vás, že názory na tyto věci se liší a to je v pořádku.
2. Umožňují vám vytvářet a prosazovat vlastní názory (nebo týmový konsensus) pomocí konfigurovatelných nástrojů.

Dohadováním se o názorových pravidlech opravdu nic nezískáte. Vezměte si ty, které se vám líbí, zapomeňte na ty, které se vám nelíbí.

Doufám, že se podíváte na správné šipky a zjistěte, jestli tam není něco, co byste mohli použít k zajištění vašeho => funkce šipky jsou nejlepší formou, kterou mohou být ve vaší kódové základně.

A pokud v pluginu chybí nějaká pravidla, která by pomohla definovat více správných šipek , napište problém a můžeme diskutovat! Je zcela pravděpodobné, že toto pravidlo/režim můžeme přidat, i když osobně plánuji nechat to vypnuté!

Nenávidím => funkce šipky a vy byste také neměli. Jen nesnáším neinformované a neukázněné debaty. Přijměme chytřejší a lépe konfigurovatelné nástroje a pojďme k důležitějším tématům!