Puster luft ind i AirBnBs JavaScript Style Guide

Ingen planlægger at skrive grim, inkonsekvent stilkode. Det sker bare slags.

Selv som den eneste udvikler på et projekt, jo mere tid der går, og jo mere kode du skruer ud, jo sværere bliver det sværere at opretholde en ensartet kodestil.

Derfor har du brug for en stilguide.

Jeg har oplevet fra første hånd, hvor meget flere hold kan opnå efter at have vedtaget en stilguide.

Du behøver ikke længere foretage ringe stilvurderinger gennem dagen. Bare konsulter stilguiden.

Og når en holdkammerat skal vedligeholde din kode, er det ren kode, som de kan læse og forstå.

Vedtagelse af en stilguide er en af ​​de nemmeste ting, du kan gøre for at øge din kodes vedligeholdelse - hvilket i sidste ende øger dit teams produktivitet. Så lad os udforske den mest populære måde at gøre dette på.

Indtast AirBnB + ESLint

JavaScript-økosystemet tilbyder en bred vifte af værktøjer og stilguider. Dette burde ikke overraske nogen. med JavaScript forventer vi en bred vifte af alt.

Men efterhånden som økosystemet modnes, begynder erfarne udviklere at længes efter "den normale måde" at gøre ting på, som mere størknede økosystemer tilbyder.

Du er selvfølgelig velkommen til at bruge et par dage på at udforske JavaScript-økosystemet og sammenligne forskellige værktøjer, men jeg vil prøve at spare dig tid : ESLint er det mest populære JavaScript-linting-værktøj, og AirBnBs stilguide er det mest anvendte stil guide.

For flere detaljer om tilføjelse af ESLint til dit projekt, tjek dette link.

Når du først har det, kan du konfigurere dit projekt til at håndhæve AirBnBs stilvejledning ved at installere deres npm-pakke:

npm install --save-dev eslint-config-airbnb

Tilføj følgende linje i din .eslintrc- fil

"extends": "airbnb"

Og voilà! Din kode er nu underlagt reglerne i den mest populære JavaScript-stilvejledning. God kodning!

Standarder overvurderes

Mens jeg er enig i de fleste regler i stilguiden, er her en liste over tilsidesættelser, som jeg har samlet. Sådan ser .eslintrc- filerne i projekternes rodmapper ud:

Lad mig forklare ræsonnementet bag hver af disse tilpasninger i detaljer.

Indrykning

Fanerne VS rumkrig kan potentielt ødelægge venskaber og muligvis endda sabotere romantiske forhold.

Jeg foretrækker at indrykke mine 4-pladser, selvom langt størstedelen af ​​konfigurationer derude foretrækker en indrykning på 2.

Min begrundelse er, at for at skrive ren kode, giver større fordybninger dig en bedre visuel repræsentation af, hvor dybt indlejringen er i dine funktioner, og hvor mange forskellige grene du har.

Du bør bestemt ikke indlejre kode dybere end 3 eller 4 lag inde i en JavaScript-fil (det er en kodelugt). Så at have 4 mellemrum giver dig bedre læsbarhed, mens du bevarer andre regler som at holde din kode inden for en grænse på 80 eller 120 tegn pr. Linje.

Indrykning er også en af ​​de regler, der trækker mere ”luft” ind i AirBnBs standardstilguide. Som et resultat samles din kode ikke så dårligt på venstre side af editoren.

Afstand

Dette er sandsynligvis den største afvigelse fra standarden. Jeg hader overfyldt kode. Jeg begyndte at skrive kode med ekstra pladspolstring for mere end 2 år siden, og jeg så aldrig tilbage.

Så hvad betyder disse regler? Nå, se på følgende kode. Det respekterer teknisk reglerne i AirBnBs officielle stilvejledning.

Jeg ved, det er lidt forvirrende. Jeg forsøgte at lede efter en medium kompleksitetsfunktion fra en af ​​mine kodebaser, men jeg var nødt til at skjule meget af det, så prøv ikke at forstå logikken bag koden (fordi der ikke er nogen). Bare prøv at læse det. Forsøg at fokusere for eksempel på variabler, der bruges flere steder, når parametre overføres til funktioner, og hvor funktionsopkaldene er.

Se nu på den samme kode, men med de ekstra afstandsregler, der anvendes:

Jeg siger ikke, at det er meget læsbart nu, men du kan lettere identificere, hvor du har parametre sendt til funktioner - især omkring de karrige funktioner.

Kontroller også forskellen mellem 2- og 4-pladsindrykket i de to eksempler.

Først virker disse teknikker måske ikke som en stor forbedring. Jeg opfordrer dig til at prøve dem. Jeg tror, ​​du hurtigt vil opleve, hvilken forskel det gør.

Citat krige

Mens de to første kategorier havde nogle klare argumenter, må jeg sige, at beslutningen om single vs dobbelt citater er meget subjektiv.

Min præference for dobbelt citater kommer sandsynligvis fra at arbejde meget med React, hvor du blander JavaScript med JSX-tags. Da JSX er tættere på HTML, er tendensen at tilføje attributter mellem dobbelt anførselstegn. Så jeg begyndte at bruge dobbelt anførselstegn for alt, bare for konsistens.

En ting, jeg har bemærket, er at det er meget mere sandsynligt, at du har brug for at skrive et enkelt citat inde i en streng engelsk tekst end et dobbelt citat ("Jeg er her", "Gør ikke det"). Så dobbelt citater kan være mere bekvemme i disse tilfælde.

Kode arrangement

Den officielle AirBnB-stilvejledning har en "no-use-before-define" -regel, som kaster en fejl, hvis du prøver at bruge noget, før du definerer det. Dette er en god regel - især for variabler - fordi du ikke skal stole på hejsning, og du skal huske det tidsmæssige døde zoneproblem i tankerne, når du bruger let og const.

Jeg foretrækker at tillade, at funktioner bruges, før de defineres. Årsagen er enkel: det meste af tiden vil du opdele dine funktioner i mindre underfunktioner. Imidlertid vil "no-use-before-define" -reglen fortælle dig at sætte disse underfunktioner før den oprindelige funktion.

Men dine underfunktioner er der for at abstrakte dele af algoritmen. De bør ikke genere dig, når du åbner en fil, der indeholder din øverste niveau-funktion , som du bruger uden for filen.

Selvfølgelig er dette diskutabelt. Men det påvirker fejlretning. Når du gentager noget kode, og du finder et opkald til en anden funktion, skal du ideelt set være i stand til at se under det, eller - i værste fald - rul ned gennem et par underfunktioner og find det, du leder efter.

Dette, kombineret med Airbnb funktion erklæring mod funktionen udtrykHerske,kan give dig friheden til at strukturere dine moduler eller funktionsbiblioteker, som du vil, samtidig med at du ikke ved et uheld kalder en ikke-initialiseret funktion.

Const over lad

Her er en anden lille afvigelse fra stilguiden. Du kan bemærke i min konfiguration:

"prefer-const": 1

I AirBnB-konfigurationen er dette indstillet til 2, hvilket står for fejl , mens 1 står for advarsel .

Nu, hvis du ikke forstår, hvorfor du foretrækker const frem for let, kan du læse mere om det her og her.

Med hensyn til min afvigelse foretrækker jeg en advarsel, fordi der er situationer, hvor du ikke ændrer tildelingen af ​​en variabel, men du ændrer meget af dens indhold.

Se på denne kode:

Reglerne fortæller dig, at dette er rigtigt - hash skal være const, fordi det ikke er tildelt igen. Men det gav mig aldrig rigtig mening. Jeg skal være opmærksom på, at der sker en hel del ændringer inden i hash.

Så jeg vil bruge let til at signalere det faktum, at variablen kan ændres. const and let bør give dine variabler mere mening og bør ikke skjule sandheden på nogen måde.

Kodekompleksitet

Du kan cyklomatisk kode kompleksitet for at beregne kompleksiteten af ​​hver af dine funktioner.

Det er vanskeligt at beslutte et maksimalt kompleksitetsniveau. Ideelt set skal det være så lavt som muligt, hvilket betyder, at dine funktioner højst skal have 1 eller 2 forgreningsmuligheder.

Det giver mening at have dette antal så lavt som muligt set ud fra genbrug og test af kode. Men der er tidspunkter, hvor det er sværere at nedbryde funktioner. Derfor ser jeg kompleksiteten mere som en advarsel end som en fejl.

Det vigtige her er at begrænse antallet af funktioner, der når den maksimale kompleksitetsgrænse. Selv i en mellemstor codebase vil jeg ikke se mere end 10 funktioner, der bryder denne regel. Så jeg valgte den maksimale værdi på 5 for at fremhæve disse funktioner. Jeg målretter mod disse funktioner, når jeg har tid til at foretage en refactoring.

Kompleksitet kan løses på flere måder. Omdannelse til mindre funktioner er den åbenlyse. En anden mulighed er at omdanne dine switch- erklæringer til kortlægningsopgaver.

Vi havde flere debatter inde i vores team, og vi endte med at bruge 5 som en referenceværdi for den maksimale kompleksitetsregel. Men i nogle tilfælde går vi ned til 4, bare for at være sikker på, at vi skriver ren og enkel kode.

En note om React

Fordi jeg arbejder meget med React, og AirBnB-konfigurationen også indeholder et stort antal regler i dette område, ville jeg også medtage nogle af mine præferencer om disse her.

Hovedmålet med mine React-tilsidesættelser er at begrænse forskellen mellem almindelige JavaScript-moduler og React-komponenter såvel som mellem JavaScript-kode og JSX. Derfor vælger jeg lignende indrykning og brugen af ​​dobbelt anførselstegn for alle JSX-attributter. Og det er derfor, jeg foretrækker at lade alle mine filer være med .js-udvidelsen.

Endelig, relateret til klasse vs fabrikskomponenter, har jeg en tendens til at foretrække sidstnævnte. Jeg ser ingen fordel ved at bruge klasser på dette tidspunkt. Jeg skriver muligvis et fremtidigt indlæg, der uddyber, hvorfor jeg har det sådan.

Det handler om det! Jeg håber du nød at læse dette. Jeg glæder mig over din feedback nedenfor.

Hvis du kunne lide artiklen, skal du klikke på det grønne hjerte nedenfor, så ved jeg, at min indsats ikke er forgæves.