10 tip til skrivning af renere & bedre kode

Reklame

Uden tvivl er programmering hård. Det er en ting at gøre lære sprog og studere algoritmer, men det er et helt andet udyr, der prøver at kode et komplekst fungerende program, der ikke får dig til at ønske at klø dine øjne.

På en måde er det at skrive ren kode meget som tegning, madlavning eller fotografering - det ser lettere ud, end det faktisk er. Så hvorfor gider det? Fordi fordelene er det værd:

• Problemer bliver lettere at løse. Når du begynder at tænke i ren kode, ændres din tilgang til problemløsning. I stedet for løsninger til brute-tvang, bliver dine algoritmer og softwaredesign mere elegante og forsætlige.
• Mindre tid spildes på vedligeholdelse. Ren kode er lettere at læse og forstå, så du bruger mindre tid på at finde ud af, hvad visse segmenter faktisk gør, og mere tid på at rette, revidere, udvide osv.
• Idéer kommunikeres tydeligere. Hvis du arbejder med andre programmerere, reducerer ren kode sandsynligheden for misforståelser mellem jer alle, hvilket også betyder færre fejl i det lange løb.

Sådan kan DU begynde at skrive ren kode.

1. Brug beskrivende navne

Hvad er variabler, klasser og funktioner? Der er mange måder at svare på, men når du virkelig tænker over det, er disse ting intet andet end grænsefladen mellem en programmør og den underliggende logik i et program.

Så når du bruger uklare og ikke-deskriptive navne til variabler, klasser og funktioner, du tilslører i det væsentlige applikationslogikken fra enhver programmør, der læser koden, inklusive dig selv.

”Jeg er ikke en stor programmør; Jeg er bare en god programmør med gode vaner. ”
- Kent Beck

Hvad hedder en variabel DXY faktisk betyder? Hvem ved. Du bliver sandsynligvis nødt til at læse hele koden for at vende dets betydning. På den anden side er betydningen af ​​en variabel ligesom distanceBetweenXY kan genkendes med det samme.

Det samme gælder klasser og funktioner. Forlig dig ikke med CalcTan () når du kan gå efter CalculateTangent () eller CalcTangentAngle () i stedet.

2. Giv hver klasse / funktion et formål

Har du nogensinde kiggede inde i en funktion, der var hundreder eller endda tusinder af linjer lang? Hvis du har det, ved du hvor meget af en smerte det kan være at gennemse, forstå og redigere. Kommentarer kan kun hjælpe i begrænset omfang.

"Programmering bryder en stor umulig opgave i flere små mulige opgaver."
- Jazzwant

Ren kode er opdelt i atombunker. Hver funktion skal sigte mod at gøre en enkelt ting, og hver klasse skal sigte mod at repræsentere et bestemt koncept. Dette er selvfølgelig en forenkling, men når du er i tvivl, er enklere renere.

I praksis en kompleks beregning som GetCreditScore () kan være nødvendigt at blive opdelt i flere hjælpefunktioner som GetCreditReports (), ApplyCreditHistoryAge (), og FilterOutstandingMarks ().

3. Slet unødvendig kode

Denne dårlige vane er en, som jeg stadig kæmper med fra tid til anden. Det sker normalt sådan: Jeg vil rette eller optimere et stykke kode, så jeg kommenterer det og udskriver lige under det - og selvom det fungerer, opbevarer jeg den gamle kode der bare i tilfælde af.

”Er det muligt, at software ikke er som noget andet, at det er beregnet til at blive kasseret: at hele pointen er altid at se det som en sæbebobler?”
- Alan J. Perlis

Over tid akkumulerer jeg en hel masse kommenterede blokke med kode, der ikke længere er behov for, men endnu ikke har rodet i mine kildefiler. Og det sjove er, at i mange tilfælde har den omkringliggende kode udviklet sig, så den kommenterede kode ville ikke fungere, selvom den gendannes.

Sagen er, at denne praksis med at kommentere “backup-kode” blev forældet af kildekontrol. Hvis du ikke bruger noget som Git eller Mercurial, skal du gøre det start med at bruge kildekontrol med det samme. Renere kode venter på dig.

Husk, det er også vigtigt at undgå at skrive gentagne koder, som du nemt kan udføre med en internetramme. Her er et par stykker webrammer værd at lære som udvikler 5 Webrammer værd at lære for udviklereEr du interesseret i at lære avanceret webudvikling? Undgå i stedet at skrive gentagne koder til disse webudviklingsrammer. Læs mere .

4. Læsbarhed> Cleverness

For mange programmerere sammenvejer “ren kode” med “smart code”, som om at komprimere ti linjer til en eller anden måde er renere. Selvfølgelig, det tager mindre plads på skærmen, men er det faktisk lettere at forstå? Nogle gange måske. Men det meste af tiden? Ingen.

”Alle ved, at fejlsøgning er dobbelt så hårdt som at skrive et program i første omgang. Så hvis du er så klog som du kan være, når du skriver det, hvordan vil du nogensinde debugge det? ”
- Brian W. Kernighan

Jeg tror, ​​programmerere elsker smarte kode, fordi det føles som et løst puslespil eller gåte. De fandt en speciel og unik måde at implementere noget på - en "genvej", hvis du vil - og det fungerer næsten som en validering af programmørens evner.

Men for at skrive ren kode, skal du forlade dit ego ved døren.

Optimer altid koden til den næste person, der læser den, fordi det sandsynligvis er næste person faktisk bliver du og der er intet mere skammeligt end at være ude af stand til at læse eller forstå din egen dygtighed.

5. Behold en konsekvent kodningstil

jeg har intet imod god programmering tutorials Hvad gør en god programmeringsvejledning?Ikke alle programmeringsvejledninger gøres lige. Nogle gavner dig og andre ender med at spilde din tid. Her er hvad man skal kigge efter i en programmeringsvejledning af høj kvalitet. Læs mere , men en af ​​ulemperne er, at nybegynder ender med at opsamle en lang række modstridende vaner, især da de vedrører kodningstil.

Jeg er ikke her for at erklære, at en stil er bedre end en anden. Hvis du vil have seler på deres egne linjer, skal du gå efter det. Hvis du vil gå foran metodekald med mellemrum, skal du fint. Hvis du foretrækker faner frem for mellemrum, skal du ikke lade mig overbevise dig om andet.

Men uanset hvad du gør, skal du være konsekvent!

Smukke er bedre end grimme.
Eksplicit er bedre end implicit.
Enkelt er bedre end komplekst.
Kompleks er bedre end kompliceret.
Flad er bedre end indlejret.
Sparsom er bedre end tæt.
Læsbarhed tæller.
- Tim Peters, Zen af ​​Python

Hvis du vil bruge det camelCaseNaming for variabler, forfalsk det ikke med underscore_naming. Hvis du bruger GetThisObject () et sted, gå ikke med FetchThatObject () et andet sted. Og hvis du blander faner og mellemrum, fortjener du at få fjernet dit tastatur.

Bestem, hvad du vil gøre fra starten, og hold dig med det igennem og gennem. Nogle sprog, som Python og C #, har sproglige stilguider, som du måske ønsker at følge.

6. Vælg den rigtige arkitektur

Der er mange forskellige paradigmer og arkitekturer, som du kan bruge til at oprette dine projekter. Bemærk, hvordan dette tip handler om at vælge højre en til dine behov, ikke om at vælge bedst en derude. Der er ingen "bedste" her.

"Uden krav og design er programmering kunsten at tilføje bugs til en tom tekstfil."
- Louis Srygley

For eksempel er MVC-modellen (Model-View-Controller) meget populær lige nu i webudvikling, fordi det hjælper med at holde din kode organiseret og designet på en måde, der minimerer vedligeholdelsesindsatsen.

Tilsvarende er Entity-Component-System (ECS) mønster meget populært lige nu i spiludvikling, fordi det hjælper med at modulere spildata og -logik på en måde, der gør vedligeholdelse lettere, alt sammen med at producere kode, der er lettere at gøre Læs.

7. Beher sprogets idéer

En af vanskelighederne i mestring af et nyt programmeringssprog 7 Nyttige tricks til at mestre et nyt programmeringssprogDet er okay at blive overvældet, når du lærer at kode. Du vil sandsynligvis glemme tingene så hurtigt, som du lærer dem. Disse tip kan hjælpe dig med at bevare alle de nye oplysninger bedre. Læs mere lærer nuancerne, der adskiller det fra alle andre sprog. Disse nuancer kan være forskellen mellem grim, indviklet kode og smuk, let at vedligeholde kode.

Overvej Python, Java og JavaScript. De er alle ekstremt forskellige fra hinanden i en grad, der kræver en forskellige måder at tænke på afhængigt af hvilket sprog du vælger at bruge.

"Et sprog, der ikke påvirker den måde, du tænker på programmering, er ikke værd at vide."
- Alan J. Perlis

Mens Python handler om kompakt kode og ænder at indtaste, er Java mere i retning af verbositet og eksplicit. Hvert sprog har idiomer (såsom listeforståelser i Python), der tilskynder til en bestemt måde at kode på. Du ville gøre det godt at lære dem.

Der er også “antimønstre” at bekymre sig om, som i det væsentlige er suboptimale designmønstre, der resulterer i ineffektiv, upålidelig eller på anden måde dårlig kode. Undersøg og aflær alle de almindelige antimønstre relateret til dit valg af sprog.

8. Undersøg Masters Code

Hvis du vil skrive ren kode, er det bedste, du kan gøre, at se, hvordan ren kode ser ud og prøve at gøre det forstå hvorfor det er sådan det er - og der er ingen bedre måde at gøre dette på end ved at studere kildefilerne til industri mestere.

Det er klart, at du ikke bare kan komme ind i Microsofts hovedkvarter og kigge på deres projekter, men du kan altid gennemse kendte open source-projekter Sådan vises og redigeres kildekoden til en open source-appSelvom det at gå open source muligvis er et godt valg, skal du også investere i det rigtige samfund. GitHub er et af de bedste steder at gøre dette, ikke kun på grund af det store beløb ... Læs mere . Ved du ikke, hvor du skal starte? Prøv udstillede projekter på Github.

”Enhver nar kan skrive kode, som en computer kan forstå. Gode ​​programmører skriver kode, som mennesker kan forstå. ”
- Martin Fowler, Refactoring: Forbedring af designet til eksisterende kode

Det er trods alt en af ​​grundene hvorfor der findes open source-projekter Hvorfor bidrager folk til open source-projekter?Open source-udvikling er software fremtid. Det er fantastisk for brugere, fordi open source-software normalt er tilgængelig gratis og ofte mere sikker at bruge. Men hvad tvinger udviklere til at bidrage med kode gratis? Læs mere : så andre kan lære af dem. Og hvis du beslutter at bidrage til et sådant projekt, det kan fremskynde læringsprocessen 5 Projektideer til at hjælpe dig med at lære programmering hurtigereDer er nogle få måder at lette læringskurven for programmering. Få dine hænder beskidte, og lær hurtigere med sideprojekter, du kan starte når som helst. Leg rundt med disse fem. Læs mere .

Personligt er den allerførste gang jeg så virkelig ren kode, da jeg snublede over en bestemt hobbyers open source Python-projekt. Koden var så overvældende elegant, at jeg næsten sluttede med programmeringen, men det endte med at lære mig meget.

9. Skriv gode kommentarer

“Skriv gode kommentarer” er det ældste råd i programmeringsverdenen. Så snart nybegynder introduceres til kommentarer, opmuntres de stort set til at kommentere så ofte som de kan.

Men det føles næsten som om vi har svinget for langt i den modsatte retning. Især nybegynderne har en tendens til at overkommentere - beskrive ting, som ikke behøver at blive beskrevet og mangler pointen om, hvad en ”god kommentar” faktisk er.

"Kode altid som om den fyr, der ender med at opretholde din kode, vil være en voldelig psykopat, der ved, hvor du bor."
- John Woods

Her er en god tommelfingerregel: kommentarer findes for at forklare, hvorfor der findes et stykke kode snarere end HVILK koden faktisk gør. Hvis koden er skrevet rent nok, skal den være selvforklarende hvad den gør - kommentaren skal kaste lys over hensigten bag, hvorfor den blev skrevet.

Kommentarer kan være gode til advarsler (dvs. "at fjerne dette vil bryde A, B og C") men for det meste bør afslør ting, der ikke umiddelbart kan hentes fra koden (dvs. "brug denne parameter, fordi X, Y og Z”).

10. Refactor, Refactor, Refactor

Ligesom redigering er en del af skriveprocessen, er refactoring en del af kodningsprocessen. En modvilje mod refactoring er den hurtigste måde at ende med uoverholdelig kode på, så på mange måder er dette faktisk det vigtigste tip at overveje.

Kort sagt, refactoring er bare en fancy udtryk for at rydde op i koden uden at påvirke dens faktiske opførsel.

”Hver gang jeg skal tænke for at forstå, hvad koden gør, spørger jeg mig selv, om jeg kan refaktorere koden for at gøre denne forståelse mere øjeblikkelig synlig.”
- Martin Fowler, Refactoring: Forbedring af designet til eksisterende kode

En smule visdom, der har sat mig fast, er ordsproget, ”Kommenter ikke dårlig kode. Omskriv det. ” Som Fowler forklarer i citatet ovenfor, hvis koden nogensinde føles forvirrende nok til at du har brug for at kommentere den, måske har du faktisk brug for at refaktorere den.

Når du endvidere redigerer kodestykker her og der gennem hele dit projekt, lad altid koden være i bedre tilstand, end da du først fandt den. Det kan se ud som en gener i øjeblikket, men det vil betale sig i det lange løb (og kan endda afværge mental udbrændthed Programmering af udbrændthed: Sådan genvinder du din mistede motivationSkrivning af alle disse kodelinjer kan drænes fysisk og følelsesmæssigt. Alt hvad du behøver for at komme op igen er bevidstheden om, at motivation kan genvindes. Læs mere ).

Der er altid noget nyt at lære

En programmør, der lærer at skrive ren kode, svarer til en forfatter, der lærer at skrive ren prosa: der er ikke en rigtig måde at gøre det i sig selv, men der er masser af forkerte måder at gøre det på, og det vil tage år at mestre.

Nogle mennesker har ikke, hvad det kræver og til sidst ender med at afslutte programmeringen for godt 6 tegn på, at du ikke har til hensigt at være programmererIkke alle er udskåret til at være programmerer. Hvis du ikke er helt sikker på, at du er beregnet til at være programmør, er her nogle tegn, der kan pege dig i den rigtige retning. Læs mere - og det er fint, fordi der er masser af andre tekniske job, der ikke involverer kodning Kodning er ikke for alle: 9 tekniske job, du kan få uden detBliv ikke afskrækket, hvis du vil være en del af det tekniske felt. Der er masser af job for mennesker uden kodningsevner! Læs mere . Men for alle andre er ren kode noget, der er absolut værd at stræbe mod, selvom det tager resten af ​​dit liv at komme dertil.