Når du begynder at læse mere og mere om softwareudvikling, kommer du ofte på tværs af udtrykket "ren kode". I sin reneste form er det kode, der er nemt for andre at læse. Det er ekspressivt og smukt, og du kan nemt skelne sin hensigt simpelthen ved at se på det .
At skrive ren kode er lettere sagt end færdig.
Uanset om du er en Arduino Kom i gang med Arduino: En nybegyndervejledning Kom godt i gang med Arduino: En nybegyndervejledning Arduino er en open source elektronik prototypeplanlægning baseret på fleksibel, brugervenlig hardware og software. Det er beregnet til kunstnere, designere, hobbyister og alle interesserede i at skabe interaktive objekter eller miljøer. Læs mere tinkerer, eller du bygger Hindbær Pi Hindbær Pi: Den uofficielle Tutorial Hindbær Pi: Den uofficielle Tutorial Om du er en nuværende Pi ejer, der ønsker at lære mere eller en potentiel ejer af denne kreditkortstørrelsesenhed, er dette ikke Det er en guide, du vil savne. Læs flere applikationer med Python, eller du er endda en webudvikler. Der er nogle nyttige tips til at følge, der gør din kode lettere at læse af andre. Her er hvad du behøver at vide .
Være konsekvent
Måske er det første og mest oplagte tip at være konsekvent i hvad du gør. Et godt eksempel på dette følger de samme mønstre, når man navngiver funktioner. Den absolutte basis for programmering for begyndere (del 2). Det absolutte grundlag for programmering for begyndere (del 2) I del 2 af vores absolutte begyndere guide til programmering vil jeg være dækker grundlæggende funktioner, returværdier, sløjfer og conditionals. Sørg for at du har læst del 1, før du behandler dette, hvor jeg forklarede ... Læs mere og variabler Grundlæggende om Computer Programmering 101 - Variabler og datatyper Grundlæggende om Computer Programmering 101 - Variabler og datatyper Efter at have introduceret og snakket lidt om Objektorienteret programmering før og hvor dets navnebringer kommer fra, jeg troede det er på tide, vi går igennem de absolutte grunde til programmering på en ikke-sproglig måde. Dette ... Læs mere. Du bør vælge en navngivningskonvention og holde fast ved det.
Så, hvilken navngivningskonvention skal du bruge?
Nå, hvis du skriver Python for Raspberry Pi, er svaret klart. PEP-8-standarden (barometeret for god, ren Python-kode) siger, at variable navne skal være små, 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 såkaldte Camel Case. Her er ord ikke adskilt af noget, men det første bogstav i hvert ord er kapitaliseret, bortset fra det første ord. For eksempel: buttonPressed og temperatureReading .
Der er selvfølgelig andre stilarter med variabel navngivning. Ovenstående er simpelthen det anbefales af de officielle stil guider. Men hvad end du vælger, skal du sørge for at holde fast ved det og bruge den samme navngivningskonvention gennem hele dit program.
Skriv betydningsfulde kommentarer
Kommentarer er en god måde at forklare, hvad dit program gør. Du kan angive, hvad hver funktion gør, og hver variabel repræsenterer i 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, som du i sidste ende forstår det bedre.
Men hvis du ikke skriver dine kommentarer på en måde, der er indlysende og udtryksfuld, så kan du ikke lige så godt forstyrre.
Når du skriver kommentarer, bør du prøve og forklare hvorfor af koden, ud over hvordan. Prøv at gøre hensigten rigeligt klart, og sig noget om koden, som den ikke kan sige sig selv. Så i stedet for:
// opdatering læsning
Overvej at skrive:
// Opdater antallet af gange laserstrålen er blevet brudt, før tweeting det ud
Sørg for at skrive i fuld grammatisk korrekte sætninger. Desuden 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 dig for at frigive din kode som open source, da engelsk er stort set den sproglige softwareudvikling.
Arduino-stilguiden går endnu længere, og siger, at du skal kommentere hver kodeblok, hver for sløjfe og hver variabel angivelse.
Personligt synes jeg det er lidt ekstremt. Hvis du skriver verbose, ekspressive variabelnavne, så 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 for første gang Sådan lærer du programmering uden al stress Sådan lærer du programmering uden al stress Det er måske du har besluttet at forfølge programmering, uanset om du er en karriere eller bare som en hobby. Store! Men måske begynder du at føle dig overvældet. Ikke så stor. Her er hjælp til at lette din rejse. Læs mere, du er ofte fyldt med en enorm rush af entusiasme. Du læser alt hvad du kan om dit valgte sprog, ramme eller platform. Du begynder at møde koncepter, du aldrig vidste 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 om en "hvis erklæring" som denne:
int x = 5; if ( 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); Ternære operatører er helt sikkert seje, og jeg opfordrer dig til at læse 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.
Arduino-stilguiden opfordrer også dig til at undgå pointers, #define statements og andre datatyper end standard: boolsk, char, byte, int, usigneret int, lang, usigneret lang, flyde, dobbelt, streng, array og tomrum. Du bør undgå datatyper som uint8_t, da disse er mindre almindeligt anvendt, ikke forklaret i dokumentationen, og ikke forfærdeligt tæve.
Indent, og drage fordel af Whitespace
Når det kommer til at skrive ren kode, er Python-brugere til en fordel, da standard Python-tolk mandatiserer, at al kode skal være fornuftigt struktureret og indrykket. Hvis du ikke indrykker efter hver funktion og klassedeklaration og betinget erklæring, vil dit program simpelthen ikke løbe.
På Arduino er der intet, der stopper dig fra at skrive ustruktureret, komprimeret kode. Dette i sidste ende er svært at læse og svært at vedligeholde.
Men der er ikke noget, der hindrer dig i at strukturere din kode bedre heller.
Først skal du fastslå, hvor meget du vil indrykke ved. Du skal bruge fanen nøglefuldt, da hver tekstredigerer behandler ASCII-koden for fanebladet anderledes, og hvis du deler din kode med en anden, er der en chance for, at de uforvarende kan introducere inkonsekvenser i din indrykning. Disse uoverensstemmelser kan ødelægge dit program, især hvis du bruger et hvidspidsfølsomt sprog som CoffeeScript CoffeeScript, er JavaScript uden hovedpine. CoffeeScript er JavaScript uden hovedpine. Jeg har aldrig rigtig ønsket at skrive JavaScript så meget. Fra den dag, jeg skrev min første linje ved hjælp af den, har jeg altid irriteret, at hvad jeg skriver i det altid ender med at ligne en Jackson ... Læs mere eller Python. Denne artikel fra OpenSourceHacker forklarer mere detaljeret, hvorfor fanenøglen bør undgås.
Jeg har tendens til at bruge fire mellemrum for hvert indryk, men det samlede tal er op til dig. Bare så længe du er konsistent.
Du kan konfigurere din IDE og tekstredigerer til at behandle hver fane som et angivet antal mellemrum, men du kan dog 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 det automatisk for dig, og indsætter to mellemrum, når du trykker på fanen.
Derefter skal du blot vide, hvor du skal indrykke din kode. Som en god tommelfingerregel skal du altid indsætte efter hver funktionserklæring, og efter hver, hvis ellers, for, mens, skift og tilfælde erklæring.
Mange redaktører kommer med muligheden for at indrykke hele blokke af kode på en gang. Hvis du bruger Sublim tekst 2, kan du oprette en hurtigtast eller tastetryk kombination. Ellers kan du bruge standardkombinationen, som (på OS X) er Cmd + [ . I Arduino-editoren kan du reparere filens indrykning automatisk 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æs vejledningen !
Gentag ikke dig selv
Et af de vigtigste mantraer med god softwareudvikling er ikke gentage dig selv, som ofte forkortes til DRY.
Skrivning af DRY-kode er utrolig vigtigt, da det sikrer, at logikken i dit program er konsistent, giver dig mulighed for at foretage en ændring på et sted og få det til udtryk globalt, og du bruger mindre tid på at skrive det samme igen og igen.
Den bedste måde at blive DRY på er med en liberal og generøs brug af funktioner - indkapsling af en gentagen opgave med en blok kode, du kan ringe igen og igen - og sikre, at hver enkelt er tydelig og velskrevet.
En god funktion er kort; PEP-8-vejledningen siger lidt om funktionslængde, men Clean Code: En håndbog af Agile Software Craftsmanship af Bob Martin (stærkt anbefalet) siger, at "funktioner burde næsten aldrig være 20 linjer lange". Fortrinsvis ville de være endnu kortere end det .
Funktioner bør også gøre præcis én ting. Har du brug for en funktion, der gør to ting? Skriv to funktioner.
Disse tip gør det nemt at følge strømmen af et program, og i sidste ende debug det om nødvendigt. Der er også en ekstra fordel for Arduino brugere, der er tæt begrænset af lagringsbegrænsninger, da afskedigelser fjernes. Dette resulterer i mindre programmer.
Være eksplicit
En anden vigtig mantra af softwareudvikling er "eksplicit er bedre end implicit" . Det betyder, at din kode skal temmelig meget råbe, hvad det gør ved første øjekast. Arduino-stilguiden siger, at ting som dette bør undgås:
if(buttonPressed){ doSomething(); } I stedet skal du gøre det klart, hvad der sker. I stedet skal du skrive noget som dette:
if (buttonPressed == True){ doSomething(); } Gå ud og kode (godt)
At skrive ren kode er overraskende enkel. Du skal bare være konsekvent i alt du gør, undgå afskedigelser og være eksplicit. Husk, at ren kode er blot kode, der er læsbar.
Der er meget lækkert materiale om dette emne. Et godt udgangspunkt er Arduino vejledning og API stil guider, efterfulgt af PEP-8 standard, hvis du bygger Python apps til Raspberry Pi. Hvis du bruger et andet sprog (som Javascript på Tessel-bestyrelsen) Bygger Tesselets Internet, Med Tessel: Node.js Udviklingsstyrelsen Bygger Tingselskabet, Med Tessel: Node.js Udviklingsstyrelsen Tessel er en ny race af Udviklingspanel, der udelukkende kører på Node.js, og efter en succesfuld kickstarter, har de nu nået det til at være tilgængeligt for alle. Læs mere), se Google for en officiel stilguide.
Hvis du leder efter en mere akademisk læsning om emnet, skal du tjekke Clean Code: En håndbog af Agile Software Craftsmanship af Bob Martin. Jeg nævnte det tidligere i denne artikel, og det kommer stærkt anbefales. Selvom det bruger Java til at illustrere begreber, kan mange af ideerne videreføres til andre sprog, som Python og C for Arduino.
Der er også nogle glimrende blogindlæg på nettet, der illustrerer, hvordan man skriver god, beskrivende, ren kode. Jeg anbefaler, at du tjekker "Clean, high quality code: en vejledning om, hvordan man bliver en bedre programmør" af Arash Arabi, der skriver til butterfly.com.au og "The Fundamentals of Writing Clean Code" af Chris Reynolds, skriver til webdevstudios. com.
Selvom det ikke udtrykkeligt er relateret til ren kode, er det også nyttigt at lære, hvilke funktioner og biblioteker der bedst undgås i dit sprog. Hvis du f.eks. Lærer PHP, bør du undgå "mysql" -bibliotekerne, og hvis du opbygger fysiske produkter med Arduino, bør du aldrig bruge forsinkelsesfunktionen Arduino Delay Function, og hvorfor du ikke bør bruge det Arduino Forsinkelsesfunktion, og hvorfor du ikke bør bruge det Selvom forsinkelsen () er praktisk til grundlæggende demonstrationer af, hvordan Arduino fungerer, skal du virkelig ikke bruge det i den virkelige verden. Her er hvorfor, og hvad du skal bruge i stedet. Læs mere .
Husk, at kode, der er lettere at læse, er lettere at vedligeholde. Plus, hvis du nogensinde sætter dig fast i noget, er det nemmere for nogen at læse det og hjælpe dig.
Har du nogle tips til at skrive ren kode? Savnede jeg noget? Fortæl mig! Giv mig en kommentar nedenfor, og lad mig vide.
Foto Credits: Dry Bed (Premasagar), Little TAB Key (Kai Hendry), 2015 (Wikilogia)