Hvorfor skal du bruge kolonneindrykning for at forbedre din kodes læsbarhed

Jeg tror, ​​at det vigtigste aspekt ved programmering er læsbarheden af ​​den kildekode, du skriver eller vedligeholder. Dette involverer mange ting, lige fra programmeringssprogets syntaks til variabelnavne, kommentarer og indrykning. Her diskuterer jeg den sidste af disse, indrykning .

Det handler ikke om indrykningsstørrelse eller valget mellem faner og mellemrum, eller om det skulle kræves på et sprog som Python. Mange mennesker kan lide at bruge en maksimal linjelængde for hver linje kode, normalt 80 eller 120 tegn. Med denne idé er der ingen maksimal længde, og nogle gange bliver du nødt til at bruge den vandrette rullepanel. Men freak out, det er ikke for hele koden - det er kun for nogle dele af det.

Fire eksempler på forbedringer ved hjælp af kodeindrykket

Første eksempel

Se på denne kode:

Læsbarheden er ikke så god, og du kan ende med noget som dette for at undgå rodet:

Og dine syv linjer er blevet næsten 40 linjer. Dette med kun tre eller fire egenskaber pr. Objekt. Hvis det var otte egenskaber, ville det blive 70 linjer.

Ideen, som jeg taler om, er at bruge noget som dette (jeg kalder det "kolonneindrykket" kode):

Andet eksempel

Det er ikke kun for objektbogstaver. Det kan bruges til ethvert stykke kode, der er en gruppe af lignende linjer. Denne proces kan være hurtig. Du kan kopiere den første linje, indsætte den og derefter overskrive de skiftende stykker i hver linje.

Det kan også bruges i JS import . Sammenlign disse to versioner:

Disse tretten importer er alfabetisk sorteret efter stien. Alle kommer fra vsmappen - fem fra vs/baseog otte fra vs/platform.

Du kan ikke se det uden at bevæge dine øjne frem og tilbage på tværs af hver linje. At gøre dette er irriterende. Selvfølgelig behøver du ikke lave statistik om, hvordan dine filer importerer andre. Men på et tidspunkt vil du læse denne kode for at se, om du importerede noget fra den rigtige fil, eller om en fil allerede var importeret.

Se nu, hvordan det ser ud, når den samme kode er kolonneindrykket:

Gør det ikke det lidt bedre?

Tredje eksempel

I dette eksempel har vi en metodedeklaration fra TypeScript-kompilator:

Igen kan du lettere se forskellen mellem linjerne. Det hjælper dig med at læse alle de fem linjer på samme tid og bruge mindre kræfter. Og hvis du har brug for at tilføje en parameter i hver af disse 5 linjer, kan du gøre det kun én gang ved hjælp af multilinjemarkøren i næsten alle kodeditorer.

Fjerde eksempel

Her er det sidste eksempel med originalen og sammenligningen sammen:

Fordele :

  • Din kode ser renere ud.
  • Din kode har forbedret læsbarheden
  • Du kan muligvis reducere antallet af linjer i din kode

Ulemper :

  • Den automatiske formateringsmulighed for kodeditorer kan forstyrre layoutet
  • Når du tilføjer en linje til en linjeblok, skal du nogle gange ændre alle de andre linjer
  • Det kan være tidskrævende at skrive kode

Hvilke værktøjer kan hjælpe med at opnå dette?

Jeg lavede indrykning på denne måde manuelt i nogen tid. Det er kedeligt, men når du først gør det, kan du ikke stoppe. Du ser på din kode, alle de gentagne linjer, der kunne søjles i kolonnen for at være mere læselige, og du kan ikke fortsætte uden at gøre det. Det er vanedannende.

Jeg bruger Visual Studio og Visual Studio Code, så jeg forsøgte at finde en udvidelse eller et plugin, der hjælper med at opnå dette. Jeg fandt ingen. Så i november 2017 begyndte jeg at oprette min egen udvidelse til Visual Studio Code og kaldte den Smart Column Indenter.

Jeg offentliggjorde en første anvendelig version i samme måned. Se på, hvordan det fungerer:

Der er områder, hvor udvidelsen kunne forbedres. I øjeblikket virker det kun med *.ts, *.jsog *.jsonfiler. Jeg tror, ​​at det også kan hjælpe med XML- og HTML-filer, som kolonneindrykning af de samme attributter for gentagne tags eller forskellige tags, der gentages i en gruppe af linjer.

Når koden er valgt til kolonneindrykning, fungerer algoritmen i tre trin:

  1. Lexikal analyse (eller tokenisering) af koden. Jeg installerede TypeScript npm-pakken som en afhængighed og brugte Compiler API for at undgå at genopfinde hjulet her.
  2. Udfør LCS-algoritmen (Longest Common Subsequence), der passerer hver kodelinje som en sekvens af tokens. Dette er den hårde del. En masse referencer på internettet taler om LCS for kun to sekvenser som input, hvilket let kan løses med dynamisk programmering . Da vi normalt vil kolonneindryk mere end to kodelinjer, bliver problemet at finde den længste fælles sekvens (LCS) af flere strenge. Dette er et NP-hårdt problem. Da dette er et generisk problem, oprettede jeg en separat npm-pakke (multiple-lcs) med en grundlæggende implementering for at opnå dette. Det er ikke den bedste løsning i nogle tilfælde, men det er brugbart.
  3. Omskriv koden for at kolonneindrykke de tokens, der vises i LCS. Hvert token i LCS placeres i en ny kolonne.

For nogle typer tokens, f.eks. Navne på strenge eller variabler, bruges typenavnet i stedet for indholdet i LCS-algoritmen. Resultatet er en større undersekvens.

Jeg lagde al logikken i en separat npm-pakke (smart-column-indenter). Hvis du vil oprette en udvidelse eller et plugin som dette til en anden JavaScript-baseret IDE, kan du bruge denne pakke.

Min første grund til at skabe denne løsning var proof-of-concept. Jeg vil gerne vide, hvad andre programmører synes om min løsning. Hvis du kunne lide det, bedes du klappe .

Hvis du har konstruktiv kritik eller kender til andre værktøjer, der gør det samme, bedes du efterlade en kommentar. Dette er en artikel, som jeg fandt nyttig.

Tak for læsningen.

Opdatering (2018–03–29): Efter at den blev offentliggjort for et par dage siden, fik jeg en masse feedback, de fleste af dem er negativer, men tak alle sammen alligevel, det er godt at vide, hvorfor mange mennesker ikke kan lide det. Jeg fandt ud af senere, at folk normalt kalder det "kodejustering", du finder ikke noget om "kolonneindrykning", så hvis du vil søge mere om dette, skal du søge efter "kodejustering" i stedet. Jeg gjorde det, og jeg fandt et interessant blogindlæg fra Terence Edens blog, da de fleste af de negative kommentarer handler om problemer med VCS-fusioner, historie og beskidte forskelle, vil jeg kopiere hans konklusion: “Hvis vores værktøjer gør det bedre at forstå disse ideer vanskeligt, det er de værktøjer, der skal ændres - ikke os. ”

Opdatering (2018–05–03): Som om nogen hos GitHub-teamet havde læst de negative kommentarer om kodejustering her, kan du nu ignorere hvide mellemrum i kodegennemgang.

Opdatering (2018–05–20): Hvis du bruger Visual Studio (ikke kode), lavede Shadman Kudchikar en lignende udvidelse, kan du læse om det her eller downloade det her.

Faktoid

Vi har nu 22 "-skærme med en opløsning på 1920x1080. Der er ingen grund til at begrænse dig selv til 80 tegn pr. Linje, selvom du skal beslutte den maksimale grænse. Oprindelsen til denne grænse på 80 tegn er: