Joseph Goodman
1 
4964
465
Når du begynder med og mere om softwareudvikling, kommer du ofte over setningen “ren kode”. I sin reneste form er dette kode, der er let for andre mennesker at læse. Det er udtryksfuldt og smukt, og du kan let skelne dets intention blot ved ser på det.
At skrive ren kode er lettere sagt end gjort.
Uanset om du er en Arduino Kom godt i gang med Arduino: En begynderguide Kom godt i gang med Arduino: En begynderguide Arduino er en open source-elektronikprototypeplatform, der er baseret på fleksibel, brugervenlig hardware og software. Det er beregnet til kunstnere, designere, hobbyister og enhver der er interesseret i at skabe interaktive objekter eller miljøer. tinkerer, eller bygger du Raspberry Pi Raspberry Pi: Den uofficielle tutorial Raspberry Pi: Den uofficielle tutorial Uanset om du er en nuværende Pi-ejer, der vil lære mere eller en potentiel ejer af denne enhed med kreditkortstørrelse, er dette ikke en guide, du vil gå glip af. applikationer med Python, eller du er endda en webudvikler, er der nogle nyttige tip at følge, der vil gøre din kode lettere at læse af andre. Her er hvad du har brug for at vide.
Være konsekvent
Det første og mest åbenlyse tip er måske at være konsekvent i hvad du gør. Et godt eksempel på dette er at følge de samme mønstre, når man navngiver funktioner The Absolute Basics Of Programming For Beginners (Part 2) The Absolute Basics Of Programming For Beginners (Del 2) I del 2 af vores absolutte begynderguide til programmering, skal jeg dækker det grundlæggende om funktioner, returneringsværdier, loops og conditionals. Sørg for, at du har læst del 1, før du tackle dette, hvor jeg forklarede… og variablerne Det grundlæggende i computerprogrammering 101 - variabler og datatyper Det grundlæggende ved computerprogrammering 101 - variabler og datatyper Har introduceret og talt lidt om Objektorienteret programmering før og hvor dens navnebror kommer fra, troede jeg, at det er på tide, at vi gennemgår de absolutte grundlæggende programmering på en ikke-sprogspecifik måde. Dette… . Du skal vælge en navnekonvention og holde sig til den.
Så hvilken navnekonvention skal du bruge?
Hvis du skriver Python til Raspberry Pi, er svaret klart. PEP-8-standarden (barometeret for god, ren Python-kode) siger, at variabelnavne skal være med små bogstaver, med hvert ord adskilt af en understregning. For eksempel: gpio_input og moisture_sensor_reading.
Arduino-stilguiden siger implicit, at du skal skrive dine variabler i det, der kaldes Camel Case. Her adskilles ord ikke med noget, men det første bogstav i hvert ord aktiveres med undtagelse af det første ord. For eksempel: buttonPressed og temperatureReading.
Der er naturligvis andre stilarter med variabel navngivning. Ovenstående anbefales simpelthen af de officielle stilguider. Men uanset hvad du vælger, skal du sørge for at holde dig ved det og bruge den samme navnekonvention i hele dit program.
Skriv meningsfulde kommentarer
Kommentarer er en fantastisk måde at forklare, hvad dit program gør. Du kan angive, hvad hver funktion gør, og hver variabel repræsenterer med dine egne ord. Dette gør det nemt for en tredjepart at læse din kode, men gør også din kode lettere at vedligeholde, da du i sidste ende forstår den bedre.
Men hvis du ikke skriver dine kommentarer på en måde, der er indlysende og udtryksfuld, så er det måske ikke så godt, du gider.
Når du skriver kommentarer, skal du prøve at forklare årsagen til koden ud over hvordan. Forsøg at gøre intentionen rigeligt klar, og sig noget om koden, som den ikke selv kan sige. Så snarere end:
// opdateringslæsning
Overvej at skrive:
// Opdater antallet af gange, at laserstrålen er blevet brudt, før du twitrer den ud
Sørg for at skrive fulde, grammatisk korrekte sætninger. Derudover siger PEP-8-standarden for Python, at du altid skal skrive dine kommentarer og variabler på engelsk. Dette gør det lettere for andre at samarbejde med dig, hvis du beslutter at frigive din kode som open source, da engelsk stort set er lingua franca inden for softwareudvikling.
Guiden for Arduino-stil går endnu længere, og siger, at du skal kommentere hver kodeblok, hver for loop og hver variabel-erklæring.
Personligt synes jeg det er lidt ekstremt. Hvis du skriver ordrette, udtryksfulde variabelnavne, er din kode allerede selvdokumenterende. Når det er sagt, tøv ikke med at tilføje kommentarer, hvor du mener, at de er nødvendige. Brug din egen gode dømmekraft.
Forenkle din kode
Når du lærer at udvikle dig for første gang Sådan lærer du programmering uden al stress Sådan lærer du programmering uden al stress. Måske har du besluttet at forfølge programmering, hvad enten det drejer sig om en karriere eller bare som en hobby. Store! Men måske begynder du at blive overvældet. Ikke så stor. Her er hjælp til at lette din rejse. , er du ofte fyldt med et enormt rush af entusiasme. Du læser alt hvad du kan om dit valgte sprog, ramme eller platform. Du begynder at møde koncepter, som du aldrig kendte før, og du er alt for ivrig efter at bruge dem i din egen kode.
Ting som ternære operatører, som giver dig mulighed for at kondensere logikken i en “hvis erklæring” som denne:
int x = 5; hvis (x < 10) y = 1; else y = 0; I en enkelt linje som denne:
int x = 5; int y = (x < 10) ? 1 : 0; printf("%i\n", y); Ternary-operatører er bestemt seje, og jeg opfordrer dig til at læse videre om dem. Men når du skriver kode, der er let for andre at læse, undgås de bedst. Det er dog kun et eksempel.
Guiden Arduino-stil opfordrer dig også til at undgå pointere, #definere udsagn og andre datatyper end standarden: boolsk, char, byte, int, usigneret int, lang, usigneret lang, flydende, dobbelt, streng, array og tomrum. Du bør undgå datatyper som uint8_t, da disse er mindre almindeligt anvendte, ikke forklaret i dokumentationen, og ikke er meget stramme.
Indrykk og drage fordel af Whitespace
Når det kommer til at skrive ren kode, er Python-brugere en fordel, da standard Python-fortolker kræver, at al kode skal være fornuftigt struktureret og indrykket. Hvis du ikke indrykker efter hver funktion og klassedeklaration og betinget erklæring, kører dit program simpelthen ikke.
På Arduino er der intet, der forhindrer dig i at skrive ustruktureret, komprimeret kode. Dette er i sidste ende svært at læse og svært at vedligeholde.
Men der er heller ikke noget der forhindrer dig i at strukturere din kode.
Først skal du bestemme, hvor meget du vil indrykke ved. Du skal bruge fanenøglen med omtanke, da hver tekstredigerer behandler ASCII-koden til fanen forskelligt, og hvis du deler din kode med en anden, er der en chance for, at de uforvarende kan indføre uoverensstemmelser i din indrykk. Disse uoverensstemmelser kan ødelægge dit program, især hvis du bruger et sprogfølsomt sprog som CoffeeScript CoffeeScript er JavaScript uden hovedpine CoffeeScript er JavaScript uden hovedpine Jeg har aldrig rigtig godt ønsket at skrive JavaScript så meget. Fra den dag, jeg skrev min første linje ved hjælp af den, har jeg altid vred mig over, at uanset hvad jeg skriver i det altid ender med at se ud som en Jackson… eller Python. Denne artikel fra OpenSourceHacker forklarer mere detaljeret, hvorfor fanenøglen skal undgås.
Jeg har en tendens til at bruge fire mellemrum til hvert led, men det samlede antal er op til dig. Bare så længe du er konsekvent.
Du kan konfigurere din IDE og teksteditor til at behandle hver fane som et angivet antal mellemrum, men giver dig mulighed for at bruge fanenøglen uden risiko for at indføre problemer. Hvis du bruger Sublime Text 2, skal du tjekke deres officielle dokumentation. Hvis du bruger Vim, skal du bare redigere din .vimrc fil med disse linjer. Arduino-editoren gør dette automatisk for dig og indsætter to mellemrum, hver gang du trykker på fanen.
Derefter skal du blot vide, hvor du skal indrykke din kode. Som en god tommelfingerregel skal du altid indrykke efter hver funktionserklæring og efter hver hvis, andet, til, mens, kontakt, og sag udmelding.
Mange redaktører har muligheden for at indrykke hele blokering af kode på én gang. Hvis du bruger Sublime Text 2, kan du konfigurere en genvejstast eller tastetrykskombination. Ellers kan du bruge standardkombinationen, som (på OS X) er Cmd + [. I Arduino-editoren kan du automatisk rette din fils indrykning ved at trykke på Ctrl + T på Windows og Linux og Cmd + T på OS X.
Det afhænger helt af din editor, så læse manualen!
Gentag ikke dig selv
En af de vigtigste mantraer ved god softwareudvikling er gentag ikke dig selv, som ofte forkortes til TØR.
Det er utroligt vigtigt at skrive DRY-kode, da det sikrer, at logik i dit program er konsistent, giver dig mulighed for at foretage en ændring på et sted og få den til at reflektere globalt, og du bruger mindre tid på at skrive den samme ting igen og igen.
Den bedste måde at forblive TØR på er med en liberal og generøs brug af funktioner - indkapsling af en gentagen opgave med en kodeblok, du kan ringe til igen og igen - og sikre, at hver enkelt er distinkt og velskrevet.
En god funktion er kort; PEP-8-guiden siger lidt om funktionslængde, men Clean Code: A Handbook of Agile Software Craftsmanship af Bob Martin (stærkt anbefalet) siger, at “Funktioner skal næsten aldrig være 20 linjer”. Det ville de helst være endnu kortere end det.
Funktioner skal også gøre nøjagtigt en ting. Brug for en funktion, der gør to ting? Skriv to funktioner.
Disse tip gør det let at følge strømmen af et program og i sidste ende fejlsøge det om nødvendigt. Der er også en ekstra fordel for Arduino-brugere, der er stramt begrænset af lagringsbegrænsninger, da afskedigelser fjernes. Dette resulterer i mindre programmer.
Vær eksplicit
Et andet vigtigt mantra inden for softwareudvikling er “eksplicit er bedre end implicit”. Det betyder, at din kode stort set skal råbe, hvad den laver ved første øjekast. Gudu-stilguiden siger, at ting som dette skal undgås:
if (buttonPression) doSomething (); Snarere bør du gøre det indlysende, hvad der sker. Skriv i stedet noget sådan:
if (buttonPression == Sand) doSomething (); Gå ud og kode (godt)
At skrive ren kode er overraskende enkelt. Du skal blot være konsekvent i alt hvad du gør, undgå afskedigelser og være eksplicit. Husk, ren kode er kun en kode, der kan læses.
Der er en masse god læsestof om dette emne. Et godt udgangspunkt er Arduino-vejledninger og API-stilguider, efterfulgt af PEP-8-standarden, hvis du bygger Python-apps til Raspberry Pi. Hvis du bruger et andet sprog (som Javascript på Tessel-tavlen Building the Internet of Things, With Tessel: The Node.js Development Board Building The Internet of Things, With Tessel: Node.js Development Board Tessel er en ny race af udviklingskort, der kører helt på Node.js, og efter en vellykket Kickstarter, har de nu nået det punkt, at de er tilgængelige for alle.), tjek Google for en officiel stilguide.
Hvis du leder efter en mere akademisk læsning om emnet, så tjek Clean Code: A Handbook of Agile Software Craftsmanship af Bob Martin. Jeg nævnte det tidligere i denne artikel, og det kommer stærkt anbefalet. Selvom det bruger Java til at illustrere koncepter, kan mange af ideerne videregives til andre sprog, f.eks. Python og C for Arduino.
Der er også nogle strålende blogindlæg online, der illustrerer, hvordan man skriver god, beskrivende, ren kode. Jeg anbefaler, at du tjekker ud “Ren kode af høj kvalitet: en guide til, hvordan man bliver en bedre programmør” af Arash Arabi, der skriver for butterfly.com.au, og “Grundlæggende om at skrive ren kode” af Chris Reynolds, skriver til webdevstudios.com.
Selvom det ikke eksplicit er relateret til ren kode, er det også nyttigt at lære, hvilke funktioner og biblioteker, der bedst undgås på dit valg af sprog. For eksempel, hvis du lærer PHP, skal du undgå “mysql” biblioteker, og hvis du bygger fysiske produkter med Arduino, skal du aldrig bruge forsinkelsesfunktionen Arduino forsinkelsesfunktion, og hvorfor du ikke bør bruge den Arduino forsinkelsesfunktion, og hvorfor du ikke bør bruge den, mens forsinkelse () er praktisk til grundlæggende demonstrationer af, hvordan Arduino fungerer, burde du virkelig ikke bruge det i den virkelige verden. Her er hvorfor, og hvad du skal bruge i stedet. .
Husk, at kode, der er lettere at læse, er lettere at vedligeholde. Hvis du nogensinde sidder fast med noget, er det lettere for nogen at læse det og hjælpe dig.
Har du nogle tip til skrivning af ren kode? Gik jeg glip af noget? Fortæl mig! Efterlad en kommentar nedenfor, og lad mig vide det.
Fotokreditter: tør seng (Premasagar), Lille TAB-nøgle (Kai Hendry), 2015 (Wikilogia)