När du börjar läsa mer och mer om mjukvaruutveckling stöter du ofta på frasen “ren kod”. I sin renaste form är detta kod som är lätt för andra att läsa. Det är uttrycksfullt och vackert, och du kan enkelt urskilja dess avsikt helt enkelt genom att tittar på den.
Att skriva ren kod är lättare sagt än gjort.
Oavsett om du är en Arduino-pysslare, eller du bygger Raspberry Pi-applikationer med Python, eller om du till och med är en webbutvecklare, finns det några användbara tips att följa som gör din kod lättare att läsa av andra. Här är vad du behöver veta.
Var konsekvent
Det första och mest uppenbara tipset är kanske att vara det konsekvent i det du gör. Ett bra exempel på detta är att följa samma mönster när man namnger funktioner och variabler. Du bör välja en namnkonvention och hålla fast vid den.
Så, vilken namnkonvention ska du använda?
Tja, om du skriver Python för Raspberry Pi är svaret tydligt. PEP-8-standarden (barometern för bra, ren Python-kod) säger att variabelnamn ska skrivas med gemener, med varje ord separerat med ett understreck. Till exempel: gpio_input och moisture_sensor_reading.
Arduinos stilguide säger implicit att du ska skriva dina variabler i det som kallas Camel Case. Här är ord inte åtskilda av någonting, men den första bokstaven i varje ord är versal, förutom det första ordet. Till exempel: knapp nedtryckt och temperaturavläsning.
Det finns naturligtvis andra stilar av variabelnamn. Ovanstående är helt enkelt det som rekommenderas av de officiella stilguiderna. Men vad du än väljer, se till att du håller dig till det och använd samma namnkonvention genom hela programmet.
Kommentarer är ett bra sätt att förklara vad ditt program gör. Du kan ange vad varje funktion gör och varje variabel representerar med dina egna ord. Detta gör det enkelt för en tredje part att läsa din kod, men gör också din kod lättare att underhålla, eftersom du i slutändan förstår den bättre.
Men om du inte skriver dina kommentarer på ett sätt som är uppenbart och uttrycksfullt, kanske du inte lika gärna bryr dig.
När du skriver kommentarer bör du försöka förklara varför koden är, förutom hur. Försök att göra avsikten mycket tydlig och säg något om koden som den inte kan säga själv. Så, snarare än:
// update reading
Överväg att skriva:
// Update the number of times the laser beam has been broken, before tweeting it out
Se till att du skriver hela, grammatiskt korrekta meningar. Dessutom säger PEP-8-standarden för Python att du alltid ska skriva dina kommentarer och variabler på engelska. Detta gör det lättare för andra att samarbeta med dig om du skulle besluta dig för att släppa din kod som öppen källkod, eftersom engelska i stort sett är språket för mjukvaruutveckling.
Arduino-stilguiden går ännu längre och säger att du måste kommentera varje kodblock, varje for-loop och varje variabeldeklaration.
Personligen tycker jag att det är lite extremt. Om du skriver utförliga, uttrycksfulla variabelnamn, är din kod redan självdokumenterande. Som sagt, tveka inte att lägga till kommentarer där du tycker att de behövs. Använd ditt eget goda omdöme.
Förenkla din kod
När du lär dig att utvecklas för första gången fylls du ofta av en enorm entusiasm. Du läser allt du kan om ditt valda språk, ramverk eller plattform. Du börjar stöta på begrepp som du aldrig visste förut, och du är alltför ivrig att använda dem i din egen kod.
Saker som ternära operatorer, som låter dig kondensera logiken i en “if-sats” som den här:
int x = 5;
if ( x < 10) {
y = 1;
{ else {
y = 0;
}
På en enda rad, så här:
int x = 5;
int y = (x < 10) ? 1 : 0;
printf("%i
", y);
Ternära operatörer är verkligen coola, och jag uppmuntrar dig att läsa om dem. Men när du skriver kod som är lätt för andra att läsa, är det bäst att undvika dem. Det är dock bara ett exempel.
Arduino-stilguiden uppmuntrar dig också att undvika pekare, #define-satser och andra datatyper än standarden: boolean, char, byte, int, unsigned int, long, unsigned long, float, double, string, array och void. Du bör undvika datatyper som uint8_t, eftersom dessa är mindre vanliga, inte förklaras i dokumentationen och inte är särskilt kortfattade.
Indrag och dra fördel av blanksteg
När det gäller att skriva ren kod har Python-användare en fördel, eftersom standard Python-tolken kräver att all kod måste vara förnuftigt strukturerad och indragen. Om du inte gör indrag efter varje funktion och klassdeklaration och villkorssats, kommer ditt program helt enkelt inte att köras.
På Arduino finns det inget som hindrar dig från att skriva ostrukturerad, komprimerad kod. Detta är i slutändan svårt att läsa och svårt att underhålla.
Men det finns inget som hindrar dig från att strukturera din kod bättre heller.
Fastställ först hur mycket du ska dra in med. Du bör använda tabbtangenten med omtanke, eftersom varje textredigerare behandlar ASCII-koden för tab på olika sätt, och om du delar din kod med någon annan, finns det en chans att de av misstag kan införa inkonsekvenser i din indragning. Dessa inkonsekvenser kan bryta ditt program, särskilt om du använder ett blankstegskänsligt språk som CoffeeScript eller Python. Den här artikeln från OpenSourceHacker förklarar mer i detalj varför tabbtangenten bör undvikas.
Jag brukar använda fyra blanksteg för varje indrag, men det totala antalet är upp till dig. Bara så länge du är konsekvent.
Du kan konfigurera din IDE och textredigerare för att behandla varje flik som ett visst antal utrymmen, dock så att du kan använda tabbtangenten utan risk för problem. Om du använder Sublime Text 2, kolla in deras officiella dokumentation. Om du använder Vim, redigera bara din .vimrc fil med dessa rader. Arduino-redigeraren gör detta automatiskt åt dig och infogar två mellanslag när du trycker på tabb.
Sedan behöver du helt enkelt veta var du ska dra in din kod. Som en bra tumregel bör du alltid göra indrag efter varje funktionsdeklaration och efter varje om, annan, för, medan, växla, och fall påstående.
Många redaktörer kommer med möjligheten att dra in hela kodblock på en gång. Om du använder Sublime Text 2 kan du ställa in en snabbtangent eller en tangentkombination. Annars kan du använda standardkombinationen, som (på OS X) är Cmd+[[. I Arduino-redigeraren kan du fixa din fils indrag automatiskt genom att trycka på Ctrl+T på Windows och Linux, och Cmd+T på OS X.
Det beror helt på din redaktör, så läs manualen!
Upprepa inte dig själv
Ett av de viktigaste mantrana för bra mjukvaruutveckling är upprepa inte dig själv, som ofta förkortas till TORR.
Att skriva DRY-kod är otroligt viktigt, eftersom det säkerställer att logiken i ditt program är konsekvent, gör att du kan göra en förändring på en gång och få den reflekterad globalt, och du spenderar mindre tid på att skriva samma sak om och om igen.
Det bästa sättet att hålla sig torr är med en liberal och generös användning av funktioner – kapsla in en upprepad uppgift med ett kodblock som du kan ringa om och om igen – och se till att var och en är distinkt och välskriven.
En bra funktion är kort; PEP-8-guiden säger lite om funktionslängd, men Clean Code: A Handbook of Agile Software Craftsmanship av Bob Martin (rekommenderas starkt) säger att “funktioner bör knappast någonsin vara 20 rader långa”. Helst skulle de vara det ännu kortare än så.
Funktioner bör också göra exakt en sak. Behöver du en funktion som gör två saker? Skriv två funktioner.
Dessa tips gör det enkelt att följa flödet av ett program och att i slutändan felsöka det om det behövs. Det finns också en extra fördel för Arduino-användare, som är hårt begränsade av lagringsbegränsningar, eftersom redundanser tas bort. Detta resulterar i mindre program.
Var tydlig
Ett annat viktigt mantra för mjukvaruutveckling är “explicit är bättre än implicit”. Det betyder att din kod i stort sett borde skrika vad den gör vid första anblicken. Arduino-stilguiden säger att sådant här bör undvikas:
if(buttonPressed){
doSomething();
}
Snarare bör du göra det uppenbart vad som händer. Skriv något så här istället:
if (buttonPressed == True){
doSomething();
}
Gå ut och koda (tja)
Att skriva ren kod är förvånansvärt enkelt. Du måste bara vara konsekvent i allt du gör, undvika uppsägningar och vara tydlig. Kom ihåg att ren kod bara är kod som är läsbar.
Det finns mycket bra läsmaterial om detta ämne. En bra utgångspunkt är Arduino-tutorial och API-stilguider, följt av PEP-8-standarden om du bygger Python-appar för Raspberry Pi. Om du använder ett annat språk (som Javascript på Tessel-tavlan), kolla Google för en officiell stilguide.
Om du letar efter en mer akademisk läsning om ämnet, kolla in Clean Code: A Handbook of Agile Software Craftsmanship av Bob Martin. Jag nämnde det tidigare i den här artikeln, och det rekommenderas starkt. Även om den använder Java för att illustrera koncept, kan många av idéerna föras vidare till andra språk, som Python och C för Arduino.
Det finns också några lysande blogginlägg online som illustrerar hur man skriver bra, beskrivande, ren kod. Jag rekommenderar att du kollar in “Ren kod av hög kvalitet: en guide om hur man blir en bättre programmerare” av Arash Arabi som skriver för butterfly.com.au och “The Fundamentals of Writing Clean Code” av Chris Reynolds, skriver för webdevstudios. com.
Även om det inte är uttryckligen relaterat till ren kod, är det också bra att lära sig vilka funktioner och bibliotek som bäst undviks på ditt val av språk. Till exempel, om du lär dig PHP bör du undvika “mysql”-biblioteken, och om du bygger fysiska produkter med Arduino bör du aldrig använda Delay-funktionen.
Kom ihåg att kod som är lättare att läsa är lättare att underhålla. Dessutom, om du någonsin skulle fastna med något är det lättare för någon att läsa det och hjälpa dig.
Har du några tips för att skriva ren kod? Har jag missat något? Berätta för mig! Lämna en kommentar nedan och låt mig veta.
Fotokrediter: Dry Bed (Premasagar), Little TAB Key (Kai Hendry), 2015 (Wikilogia)
Om författaren
Matthew Hughes (383 artiklar publicerade)
Matthew Hughes är en mjukvaruutvecklare och författare från Liverpool, England. Han hittas sällan utan en kopp starkt svart kaffe i handen och fullkomligt avgudar sin Macbook Pro och sin kamera. Du kan läsa hans blogg på http://www.matthewhughes.co.uk och följa honom på twitter på @matthewhughes.
Mer från Matthew Hughes
Prenumerera på vårt nyhetsbrev
Gå med i vårt nyhetsbrev för tekniska tips, recensioner, free e-böcker och exklusiva erbjudanden!
Klicka här för att prenumerera
