Sådan vælges de bedste kodekonventioner for dig og dit team

Sæt en stopper for den uendelige debat

- "Hør, de private variabler skal gå efter de offentlige!"

- ”Ingen måde! Offentlige variabler går inden private! ”

- “Lad os spørge Deb, og lad hende beslutte”

- ”Vent, hvorfor er disse konstanter ikke kamelfarvede?”

? ‍♂? ‍♀

Løft din hånd, hvis du har fundet dig selv i denne form for diskussion før. Ok, hæv det ikke rigtig, men noget fortæller mig, at nogle af jer måske har deltaget i dette scenario en eller to gange.

Som udvikler i det sidste årti har jeg befundet mig i en hel del, nogle siger måske for mange, diskussioner om kodekonventioner. Disse diskussioner, så nyttige som de er, forværres undertiden til uendelige filosofiske vandringer. Og så begynder de at skifte til emner lige fra indrykning til mappestruktur.

Det kan være smertefuldt.

Så hvordan beslutter du virkelig, hvad den bedste konvention er, og endnu bedre: eksisterer de bedste konventioner endda? Jeg lægger det her, så du kan lægge disse filosofiske vandringer i ro, en gang for alle.

Så hvorfor har vi endda brug for konventioner?

For at afgøre, hvad den bedste konvention er, og om de overhovedet findes, skal vi først forstå, hvorfor vi endda har brug for konventioner.

Der er mere end et par grunde, men jeg vil fokusere på den vigtigste: læsbarhed .

Hvad hvis jeg besluttede at skifte til kun at skrive med store bogstaver. LIGE DETTE, SOM KAN VÆRE MÆRKLIG. Du bemærker det straks, og din hjerne begynder at behandle, hvad der er anderledes.

Tag dette enkle eksempel, og tænk på navngivning eller indrykning af variabler. Hvis hver gang du vendte tilbage til koden, og den blev skrevet forskelligt, ville det være som om du startede fra firkantet. Men når du koder med konventioner, er din kode lettere at forstå og dermed læsbar, selvom den blev skrevet for flere måneder siden.

Dette bliver endnu mere afgørende, når man arbejder på et team af udviklere, hvor hver skriver sin egen kode med deres foretrukne konvention. Den tid, der bruges til at forstå og gennemgå hinandens kode, tager ... godt ... du forstår pointen.

For at samarbejde med andre udviklere effektivt og kvalitativt skal du have en fælles konvention.

"Programmer skal skrives, så folk kan læse dem, og kun tilfældigt for maskiner, der skal udføres." - Hal Abelson

Sådan vælges den bedste kodekonvention

Uanset om du lige er begyndt at kode, eller du er en del af et kickass dev-team, eller hvis du lige er blevet CTO, hvordan skal du gå hen og vælge dine kodekonventioner?

Her er min guide til valg af den bedste kodekonvention:

  1. Få inspiration fra dev-teams, du beundrer: Intet slår oplevelsen, og nogle af de største og smarteste virksomheder offentliggør deres kodningsretningslinjer. For eksempel offentliggjorde Airbnb deres guider til javascript og rubinstil, og Google offentliggjorde deres egne Java- og Python-stilguider. Uanset om du kan lide disse virksomheder eller ej, hvis du opsummerer års erfaring, hver af deres udviklere har, tilføjer det op til gazillion. Prøv at anvende nogle af disse selskabers stilguider til dit eget team.
  2. Crowdsource-viden fra dine jævnaldrende: Vi er heldige at være en del af et så dynamisk samfund. Faktisk er vores samfund en af ​​de største fordele ved at være udvikler i dag. Uanset om det er på Slack, Spectrum, Discord eller en hvilken som helst collab-platform, kan du altid finde kyndige grupper til at stille et spørgsmål om kodekonventioner og få svar fra devs rundt om i verden med det samme.
  3. Ignorer kodeeksempler. Yup, bare ignorere dem. Nu og da snubler jeg over kode, der blev kopieret / indsat fra et svar på Stackoverflow eller noget lignende. Hvad folk nogle gange glemmer er, at kodeprøverne, de lige har kopieret, sandsynligvis blev skrevet som et svar på et teknisk spørgsmål eller som en forklaring på et bibliotek. I de fleste tilfælde mente forfatteren ikke eller havde ikke tid til at håndtere kodekonventioner.

Disse tip skal hjælpe dig i gang og kan lægge grunden til at indføre kodekonventioner til dit dev-team.

Og nu for nogle filosofi.

Findes der 'bedste' konventioner?

Det afhænger af, hvad 'bedst' betyder. Hvis Airbnb eller Google bruger en bestemt konvention, eller hvis 10 forskellige CTO'er fortalte dig, at deres konvention er den bedste - betyder det, at det er den bedste konvention for dig?

Desuden kan konventioner ændres. Kan noget, der ændrer sig over tid, nogensinde kaldes det 'bedste'?

Da jeg startede på Lemonade som den eneste front-end-udvikler, fandt jeg det svært at læse koden, som den tidligere dev skrev. Det kunne have været den bedste konvention for ham, men det var ikke for mig. Så jeg omskrev hvert stykke kode, jeg arbejdede med, ved hjælp af mine konventioner. Over tid sluttede flere udviklere sig til teamet, og vores konventioner udviklede sig.

Hver dev kom fra en forskellig baggrund med forskellige standarder og konventioner. For at formalisere vores konventioner brugte vi Airbnbs guide til javascript-stil som udgangspunkt. Vi gennemgik konventionerne i denne vejledning og ændrede eller fjernede dem, vi ikke var enige med, og vedtog dem, vi kunne lide. Vi vedtog endda konventioner, der blev hentet fra deres egen erfaring, og integrerede dem i vores mesterkonvention.

Processen med at evaluere hver konvention og beslutte, om vi skulle vedtage den, forbedrede ikke kun vores kodelæsbarhed, men forbedrede også vores teamwork. (Mere om det i et fremtidigt indlæg!)

Her er den hårde sandhed: der er ingen universel definition for de bedste konventioner, fordi de simpelthen ikke findes.

I modsætning til hvad du lærte i skolen, er der ikke altid et rigtigt svar på hvert spørgsmål. I dette tilfælde kan der være mange af dem.

Udviklere har forskellige måder at implementere forskellige eller endda de samme ting på. Nogle af os foretrækker, at alle klassemedlemmer navne begynder med et 'm_' præfiks. Nogle af os kan lide at bruge to mellemrumsindryk, nogle foretrækker faner, andre siger måske, at det at bruge ordet Utilsi et klassenavn er forkert. Hej, dette er en endeløs diskussion, men alle disse præferencer kommer med god ræsonnement.

I slutningen af ​​dagen kommer det hele ned til, hvilken konvention der forbedrer læsbarheden af ​​din kode. Hvilket gør det muligt for dit team at kommunikere bedre, komme hurtigere frem og med bedre effektivitet.

Husk, kodekonventioner er kun forslag. Ja, når du først har besluttet dig for en konvention, du skal bruge, skal du følge op. Men husk: de er ikke hugget i sten og kan ændres. Tillad dig selv at eksperimentere med forskellige konventioner, indtil du finder den bedste, der passer dig og dit team.

Så hvad er de bedste kodekonventioner? Let - din!