När du börjar läsa mer och mer om mjukvaruutveckling, kommer du ofta över formuleringen "ren kod". I sin renaste form är det kod som är lätt för andra att läsa. Det är uttrycksfullt och vackert, och du kan enkelt skilja sin avsikt helt enkelt genom att titta på den .
Att skriva ren kod är lättare sagt än gjort.
Om du är en Arduino Komma igång med Arduino: En nybörjarhandbok Komma igång med Arduino: En nybörjarhandbok Arduino är en öppen prototypplattform för öppen källkod baserad på flexibel, lättanvänd maskinvara och programvara. Den är avsedd för artister, designers, hobbyister och alla som är intresserade av att skapa interaktiva objekt eller miljöer. Läs mer tinkerer, eller du bygger Raspberry Pi Raspberry Pi: Den inofficiella självstudien Raspberry Pi: Den inofficiella handledningen Oavsett om du är en nuvarande Pi-ägare som vill lära sig mer eller en potentiell ägare av denna kreditkortstorlek, så är det här Det är en guide du vill sakna. Läs fler applikationer med Python, eller du är även en webbutvecklare. Det finns några användbara tips att följa som gör att din kod lättare kan läsas av andra. Här är vad du behöver veta .
Var konsekvent
Kanske är det första och mest uppenbara tipset att vara konsekvent i vad du gör. Ett bra exempel på detta följer samma mönster när namngivna funktioner är. Den absoluta grunden för programmering för nybörjare (del 2) Den absoluta grunden för programmering för nybörjare (del 2) I del 2 av vår absoluta nybörjarguide till programmering kommer jag att vara täcker grunderna för funktioner, returvärden, loopar och villkor. Se till att du har läst del 1 innan du klargjorde det här, där jag förklarade ... Läs mer och variabler Grundläggande för dataprogrammering 101 - Variabler och datatyper Grunderna i datorprogrammering 101 - Variabler och datatyper Efter att ha introducerat och pratat lite om Objektorienterad programmering före och där dess namnägare kommer från, jag trodde att det är dags att vi går igenom de absoluta grunderna för programmering på ett icke-språkspecifikt sätt. Detta ... Läs mer. Du borde välja en namngivningskonvention och hålla fast vid det.
Så vilken namnkonvention ska du använda?
Tja, om du skriver Python for Raspberry Pi är svaret klart. PEP-8-standarden (barometern för bra, ren Python-kod) säger att variabla namn borde vara små, med varje ord åtskilda av ett understreck. Till exempel: gpio_input och moisture_sensor_reading .
Arduino-stilguiden antyder implicit att du borde skriva dina variabler i det som kallas Camel Case. Här skiljer man inte ord från någonting, men varje ords första bokstav aktiveras, förutom det första ordet. Till exempel: buttonPressed och temperatureReading .
Det finns naturligtvis andra stilar med variabel namngivning. Ovanstående är helt enkelt det som rekommenderas av de officiella stilguiderna. Men vad du än väljer, se till att du håller fast vid det och använder samma namngivningskonvention genom hela ditt program.
Skriv meningsfulla kommentarer
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 i dina egna ord. Detta gör det enkelt för en tredje part att läsa din kod, men gör din kod enklare att behålla, eftersom du äntligen förstår det bättre.
Men om du inte skriver dina kommentarer på ett sätt som är uppenbart och uttrycksfullt, då kanske du inte alls stör.
När du skriver kommentarer, bör du försöka förklara varför av koden, förutom hur. Försök och gör avsikten rikligt klart och säg något om koden som den inte kan säga sig själv. Så, snarare än:
// uppdatering läsning
Tänk på att skriva:
// Uppdatera hur många gånger laserstrålen har brutits innan du tweeterar den
Se till att du skriver i sin helhet, grammatiskt korrekta meningar. Dessutom säger PEP-8-standarden för Python att du alltid ska skriva dina kommentarer och variabler på engelska. Det gör det lättare för andra att samarbeta med dig om du bestämmer dig för att släppa din kod som öppen källkod, eftersom engelska är ganska lingua franca för mjukvaruutveckling.
Arduino-stilguiden går ännu längre och säger att du måste kommentera varje kodblock, varje för loop och varje variabel deklaration.
Personligen tycker jag att det är lite extremt. Om du skriver verbala, uttrycksfulla variabla namn, så är din kod redan självdokumentation. Med det sagt, tveka inte att lägga till kommentarer där du tycker att de behövs. Använd din egen goda bedömning.
Förenkla din kod
När du lär dig att utveckla för första gången Hur man läser programmering utan all stress Hur man lär sig programmering utan all stress Kanske har du bestämt dig för att bedriva programmering, vare sig du är en karriär eller bara som en hobby. Bra! Men kanske börjar du känna dig överväldigad. Inte så bra. Här är hjälp för att underlätta din resa. Läs mer, du är ofta fylld med en enorm rush av entusiasm. Du läser allt du kan om ditt valda språk, ramverk eller plattform. Du börjar hitta koncept som du aldrig visste förut, och du är alltför ivrig att använda dem i din egen kod.
Saker som ternära operatörer, som låter dig kondensera logiken om ett "om uttalande" som det här:
int x = 5; if ( x< 10) { y = 1; { else { y = 0; } I en enda linje, så här:
int x = 5; int y = (x< 10) ? 1 : 0; printf("%i\n", y); Ternära operatörer är säkert coola, och jag uppmuntrar dig att läsa upp dem. Men när du skriver kod som är lätt för andra att läsa, undviks de bäst. Det är dock bara ett exempel.
Arduino-stilguiden uppmuntrar dig också att undvika pekare, #define uttalanden och datatyper än standard: booleskt, char, byte, int, osignerad int, lång, osignerad lång, flyt, dubbel, sträng, array och tomrum. Du bör undvika datatyper som uint8_t, eftersom de är mindre vanliga, inte förklaras i dokumentationen, och inte förfärligt täta.
Indrag och dra nytta av Whitespace
När det gäller att skriva ren kod, är Python-användare till en fördel, eftersom den vanliga Python-tolken förutsätter att all kod måste vara förnuftigt strukturerad och indragen. Om du inte anger efter varje funktion och klassdeklaration, och villkorligt uttalande, 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.
Först och fastställa hur mycket du kommer att dra in genom. Du borde använda fliknyckeln judiciously, eftersom varje textredigerare behandlar ASCII-koden för fliken annorlunda, och om du delar din kod med någon annan, finns det en chans att de oavsiktligt kan införa inkonsekvenser i din inryckning. Dessa inkonsekvenser kan bryta ditt program, särskilt om du använder ett spridningsspecifikt språk som CoffeeScript CoffeeScript, är JavaScript utan huvudvärk CoffeeScript är JavaScript utan huvudvärk Jag har aldrig velat skriva JavaScript så mycket. Från den dagen jag skrev min första raden med det, har jag alltid ångrat att det jag skriver i det alltid slutar se ut som en Jackson ... Läs mer eller Python. Den här artikeln från OpenSourceHacker förklarar mer detaljerat varför fliknyckeln borde undvikas.
Jag brukar använda fyra mellanslag för varje streck, men det övergripande numret ä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 mellanslag, men låter dig använda fliknyckeln utan risk för att det införs problem. Om du använder Sublime Text 2, kolla in deras officiella dokumentation. Om du använder Vim, redigera bara .vimrc- filen med dessa linjer. Arduino-redigeraren gör det automatiskt för dig och sätter in två mellanslag när du trycker på fliken.
Då behöver du bara veta var du ska ange din kod. Som en bra tommelfingerregel bör du alltid ange efter varje funktionsdeklaration, och efter varje om, annars, för, medan, växla och fallet uttalande.
Många redaktörer kommer med möjligheten att indraga hela block av kod på en gång. Om du använder Sublime Text 2 kan du ställa in en snabbtangent eller knapptryckningskombination. Annars kan du använda standardkombinationen, vilken (på OS X) är Cmd + [ . I Arduino-editoren kan du fixa filens indragning automatiskt genom att trycka Ctrl + T på Windows och Linux och Cmd + T på OS X.
Det beror helt och hållet på din redaktör, så läs handboken !
Repetera inte dig själv
En av de viktigaste mantrarna för bra mjukvaruutveckling är inte upprepa dig själv, vilket ofta förkortas till DRY.
Skrivning av DRY-kod är oerhört viktigt eftersom det säkerställer att logiken i ditt program är konsekvent, så att du kan göra en förändring på en gång och få den att återspeglas globalt och du spenderar mindre tid på att skriva samma sak om och om igen.
Det bästa sättet att hålla sig DRY är med en liberal och generös användning av funktioner - inkapslar en upprepad uppgift med ett block av kod du kan ringa om och om igen - och se till att var och en är tydlig och välskriven.
En bra funktion är kort; PEP-8 guide säger lite om funktionslängd, men Clean Code: En handbok för Agile Software Craftsmanship av Bob Martin (rekommenderas) säger att "funktioner knappast ska vara 20 linjer långa". Företrädesvis skulle de vara ännu kortare än det .
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 slutligen debugera det om det behövs. Det finns också en extra fördel för Arduino-användare, som är tätt begränsade av lagringsbegränsningar, eftersom redundanserna avlägsnas. Detta resulterar i mindre program.
Vara Explicit
En annan viktig mantra av mjukvaruutveckling är "explicit är bättre än implicit" . Det betyder att din kod ska skrika ganska mycket vad det gör vid första anblicken. Arduino-stilguiden säger att sådant som bör undvikas:
if(buttonPressed){ doSomething(); } Snarare bör du göra det självklart vad som händer. Skriv i stället något så här:
if (buttonPressed == True){ doSomething(); } Gå ut och kod (bra)
Att skriva ren kod är överraskande enkel. Du måste bara vara konsekvent i allt du gör, undvika uppsägningar och vara explicit. Kom ihåg att ren kod är enbart kod som är läsbar.
Det finns mycket bra läsningsmaterial om detta ämne. En bra utgångspunkt är Arduino handledning och API stil guider, följt av PEP-8 standarden om du bygger Python apps för Raspberry Pi. Om du använder ett annat språk (som Javascript på Tessel-styrelsen Bygga saker med Tessel: Node.js Utvecklingsstyrelse Bygga saker med Tessel: Utvecklingsstyrelsen Node.js Tessel är en ny ras av Utvecklingskortet som körs helt på Node.js, och efter en framgångsrik Kickstarter, har de nu nått punkten att vara tillgänglig för alla. Läs mer), kolla Google för en officiell stilguide.
Om du letar efter en mer akademisk läsning om ämnet, kolla in Clean Code: En handbok om Agile Software Craftsmanship av Bob Martin. Jag nämnde det tidigare i den här artikeln och det rekommenderas starkt. Även om det använder Java för att illustrera koncept, kan många av idéerna vidarebefordras till andra språk, som Python och C for Arduino.
Det finns också några fantastiska blogginlägg på nätet som illustrerar hur man skriver bra, beskrivande, ren kod. Jag rekommenderar att du kolla "Clean, högkvalitativ kod: en guide till hur du 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 uttryckligen är relaterat till ren kod, är det också till hjälp att lära sig vilka funktioner och bibliotek som bäst undviks i ditt eget språk. Om du till exempel lär dig PHP, bör du undvika biblioteken "mysql", och om du bygger fysiska produkter med Arduino, bör du aldrig använda funktionen för fördröjning av Arduino Delay och varför du inte ska använda den Arduino Fördröjningsfunktion och varför du inte ska använda den Medan fördröjning () är praktisk för grundläggande demonstrationer av hur Arduino fungerar, borde du verkligen inte använda den i den verkliga världen. Här är varför, och vad du borde använda istället. Läs mer .
Kom ihåg att kod som är lättare att läsa är lättare att underhålla. Plus, om du någonsin skulle fastna med något, är det lättare för någon att läsa den och hjälpa dig.
Har du några tips för att skriva ren kod? Missade jag något? Berätta för mig! Lämna mig en kommentar nedan, och låt mig veta.
Foto Credits: Dry Bed (Premasagar), Lite TAB Key (Kai Hendry), 2015 (Wikilogia)