Fremragende kode = ren og smuk kode

Programmer skal skrives for at folk kan læse, og kun tilfældigtvis for maskiner, der skal udføres.

Billedkreditter: unsplash.com Board

Robert Martin spikede det til perfektion, da han sagde.

"Den eneste gyldige måling af kodekvalitet er What-The-F ** ks / Minute."

Lad mig forklare lidt nærmere.

Hver gang jeg foretager kodeundersøgelse, kæmper mit sind tre forskellige følelser.

· What-the-F ** k (i afsky) - Denne kode er ikke påkrævet.

· What-the-F ** k (i beundring) - Denne fyr er smart

· Hvad-the-F ** k (i lidenskab) - ude af stand til at forstå dette gibberish

Så hvad er den allerførste ting, der påvirker os, når vi ser nogen kode?
Det er ren og smukt skrevet kode.
Og at skrive ren og smuk kode er mærket af en STORE softwarecrafters.

Der er to dele involveret i at lære dette store håndværk - viden og arbejde. Viden lærer dig de mønstre, principper, praksis og heuristik, som du har brug for for at være bedre i dit erhverv. Men denne viden skal slibes i fingrene, øjnene og tarmen ved konstant praksis og hårdt arbejde.

Så i et nøddeskal er det hårdt arbejde at lære at skrive ren kode. Du skal svede over det. Du skal øve, snuble, fejle og mestre og gentage trinene igen og igen, indtil du får det rigtigt. Der er ingen lettere måde eller trick at gøre det på.

Og her er nogle af måderne, hvorpå du kan mestre kunsten at skrive ren og smuk kode.

“Hvad er der i et NAVN”

Kendrick Lamar spikede det, da han sagde.

”Hvis jeg skal fortælle en rigtig historie, vil jeg starte med mit navn

Navne findes overalt i software. Vi navngiver vores funktioner, klasser, argumenter, pakker og hvad ikke. Vi navngiver kildefiler og mapper og alt inden for det. Vi navngiver, navngiver og navngiver løbende, og dermed bliver det den vigtigste tilstopning i vores motor med ren kode.

Dit navn skulle afsløre hensigten. At vælge gode navne tager tid, men sparer mere, end det tager, når det bliver hårdt. Så sørg for dine navne, og skift dem, når du finder bedre navne. Alle, der læser din kode, vil takke dig enormt for den.

Husk altid, at navnet på enhver variabel, funktion eller klasse skal svare på tre store spørgsmål; hvorfor det eksisterer, hvad det gør, og hvad det bruges.

Dette kræver ikke kun gode beskrivende evner, men også en fælles kulturel baggrund, der overskrider grænser, og ingen kan lære dig det bedre end dig selv.

"Funktioner bør KUN Gøre EN TING."

Louis Sullivan sagde engang smukt.

"Formular følger funktion."

Hvert system er bygget fra et domænespecifikt sprog, som er designet af programmererne til at beskrive det passende. Funktioner er verbets sprog, og klasser er navneordene. Funktioner er normalt den første organisationslinje i ethvert programmeringssprog, og at skrive dem godt er essensen af ​​at skrive god kode.

Der er kun to gyldne regler for at skrive rene funktioner:

· De skal være små

· De bør kun gøre en ting, og de skal gøre det godt

Så dette betyder, at din funktion ikke skal være stor nok til at indeholde indlejrede strukturer. Derfor skal indrykkningsniveauet for en funktion ikke være større end en eller to. Denne teknik gør det lettere at læse, forstå og fordøje. Derudover er vi nødt til at sikre, at udsagnene i vores funktion alle er på samme niveau af abstraktion.

Blanding af abstraktionsniveauer inden for en funktion er altid meget forvirrende og fører til uhåndterlig kode i rette tid. Master programmerere tænker på funktioner som historier der skal fortælles snarere end kode der skal skrives.

De bruger faciliteterne på det valgte programmeringssprog til at konstruere en rigere, udtryksfuld og renere kodningsblok, der kan fungere som en perfekt historiefortæller.

“Kommentarer kompenserer ikke for dårlig kode”

Venus Williams ramte det smell på neglen, da hun observerede.

”Alle fremsætter deres egne kommentarer. Sådan kommer rygter i gang. ”

Kommentarer er som en dobbeltkantet kniv. Intet kan være mere nyttigt end en godt placeret kommentar. På den anden side kan intet skjule mere end useriøse, ubrukelige kommentarer, der forbruger plads. Og intet kan være mere skadeligt end kommentarer, der spreder desinformation og løgne.

Så kort sagt, kommentarer er i bedste fald et nødvendigt onde. Hvorfor? ikke altid men de fleste af tiderne. Jo ældre kommentaren er, desto vanskeligere bliver det at vedligeholde dem, og de fleste programmerere har et berygtet ry for ikke at opretholde dem i overensstemmelse med deres kode.

Koden flytter og udvikler sig. Kodebiter flytter sig hit og her; kommentarer gør det ikke, og det bliver problemet!

Husk altid, at klar og ekspressiv kode med få kommentarer er langt bedre end rodet og kompleks kode med masser af kommentarer. Spild ikke tid på at forklare det rod, du har oprettet, men brug snarere tid til at rydde det rod.

“Formatering af kode er altid en prioritet”

Robert C. Martin har med rette sagt.

"Kodeformatering handler om kommunikation, og kommunikation er den professionelle udviklerens første forretningsorden."

Måske kan denne ovenstående udsagn ikke undervurderes og er en af ​​de vigtigste egenskaber ved en virkelig STOR udvikler.

En formateret kode er et vindue til dit sind. Vi ønsker, at folk skal imponere over vores ordnethed, opmærksomhed på detaljer og klarhed i tankerne. Men når de ser på koden, hvis de ser en forvirret, hotchpotch-masse af kode, der ikke har nogen klar begyndelse eller ende, der afsporer vores omdømme med det samme, er der ingen tvivl om det!

Hvis du tænker, at "få det til at fungere" er den første forretningsorden for den professionelle udvikler, kan du ikke være længere væk fra sandheden. Den funktionalitet, du opretter i dag, har en god chance for at blive ændret i den næste udgivelse, men læsbarheden af ​​din kode ændres aldrig.

Kodestilen og læsbarheden påvirker fortsat kodens vedligeholdelighed længe efter at den originale kode er blevet fuldstændigt omdannet til genkendelse.

Husk altid, at du bliver husket for din stil og disciplin og meget sjældent for koden i fremtiden. Så du skal passe på, at din kode er pænt formateret og styres af enkle regler forstået af alle holdmedlemmer.

Skriv din "try-catch-endelig" erklæring først

Georges Canguilhem observerede med rette, da han sagde.

"At fejle er menneskeligt, at vedvare ved en fejl er diabolisk."

Fejlhåndtering er noget, som alle programmerere gør. Indgange kan være unormale, og enheder kan mislykkes. Som udviklere forventes det, at vi sørger for, at koden gør, hvad den forventes at gøre. Problemet håndterer dog ikke fejlen, problemet håndterer fejlen på en ren læsbar måde.

Mange koder udfyldes domineret af fejlhåndtering. Og tingene bliver så spredte, at det udsletter fuldstændigt formålet og logikken i hovedkoden. Når det sker, er det forkert, helt forkert. En kode skal være ren og robust og håndtere fejl i nåde og stil. Det er mærket af en stor softwarehåndværker.

Og en af ​​måderne at gøre dette på er ved korrekt indkapsling og indfangning af alle fejl i try-catch-blokke. Disse blokke definerer på en måde omfanget af din kode. Når du udfører kode i try-delen af ​​try-catch-endelig-erklæringen, siger du, at udførelse kan afbrydes på ethvert tidspunkt og derefter genoptages ved fangsten.

Af denne grund er det en god praksis at starte med en try-catch-endelig erklæring, når du skriver kode. Dette hjælper dig med at definere, hvad brugeren af ​​koden kan forvente, uanset hvad der går galt med kode, der udføres i forsøget.

Husk altid, at din enhver undtagelse, du kaster, skal indeholde nok kontekst til at bestemme kilden og placeringen af ​​fejlen. Kreative informative fejlmeddelelser huskes længe efter at koden er skrevet, og programmererne har forladt organisationen.

Bringer det hele sammen

Så hvad er det eneste ord, der opsummerer alt her?

Svaret er kodefølelse; softwareækvivalent med sund fornuft.

Ifølge Robert Martin kræver "at skrive ren kode den disciplinerede anvendelse af utallige små teknikker anvendt gennem en smerteligt erhvervet fornemmelse af" renlighed ". Disse små teknikker kaldes samlet kodesans. ”

Nogle af os er født med det, og andre er nødt til smerteligt at erhverve det gennem praksis, vedholdenhed og udholdenhed. Denne kodefornemmelse hjælper os ikke kun med at skelne mellem god kode og dårlig kode, men den hjælper os også med at danne strategier til at omdanne dårlig kode til god kode.

Det viser os i lysende vendinger, at det bare ikke at bage en dejlig kage ikke hjælper, hvis du har brugt hundeskid til at frostet over den.

Denne kodefølelse hjælper programmereren med at vælge den bedste variation og det bedste værktøj til rådighed til at vejlede ham eller hende i hans bestræbelser på at skabe en værditilvækst ren og smuk kode.

Kort sagt er en programmør med kodesans en maler, der kan omdanne en blank skærm til et elegant udformet kunstværk, som vil blive husket i årene fremover.

Som Harold Abelson med rette har opsummeret.

"Programmer skal skrives for at folk kan læse, og kun tilfældigtvis for maskiner, der skal udføres."

Referencer

“En håndbog med Agile Software Craftsmanship” - Robert Martin.

“En håndbog med agile estimering” - Mike Cohn

Om forfatteren-:
Ravi Rajan er en global it-programleder baseret fra Mumbai, Indien. Han er også en ivrig blogger, Haiku poesi skribent, arkæolog entusiast og historie gal. Opret forbindelse med Ravi på LinkedIn, Medium og Twitter.

Denne historie er offentliggjort i The Startup, Medium's største iværksætterpublikation efterfulgt af +395.714 mennesker.

Abonner for at modtage vores tophistorier her.