Uppdaterad juli 2024
Den här artikeln bygger vidare på Att skriva bra kod.
- Använd bra namn
- Undvik att upprepa kod
- Indentera rätt
- Se upp med plural-s (arrayer och enskilda värden)
- Håll det enkelt
Clean Code är en bok från 2009, som handlar om att skriva bra kod. Boken omfattar många mer eller mindre avancerade koncept. Sedan den publicerades har utvecklingen gått framåt, och allt som presenteras är inte relevant. Här följer ett urval av de viktigaste principerna för den som håller på att lära sig programmering.
För att få maximal nytta av den här artikeln bör du vara bekant med variabler, funktioner och loopar.
Så fort koden börjar ett nytt block, ska innehållet indenteras. Alltså skjutas längre bort från vänsterkanten i din kodeditor. Använd Tab-tangenten en gång för att indentera. Tryck Shift-Tab för att ångra en indentering. Det finns plugin till VS Code (Prettier) som kan sköta det åt dig.
if( x === 1) {
// Denna kodrad är inte indenterad alls
if( y === 2 ) {
// Inte denna heller
}
} // Ingen indentering - svårt att se vilket block den här högerparentesen hör till!if( x === 1) {
// Korrekt indenterad, tydligt att koden är inuti if-satsen
if( y === 2 ) {
// Tydligt att koden är inuti andra if-satsen
}
} // Lätt att se att denna hör ihop med första if-satsenStäll in din kodeditor så att du har rätt indentering! VS Code: rekommenderade inställningar
Läs mer: Indentation is a code smell
Obs! När du jobbar i ett team är det viktigt att alla i teamet har samma inställning på indentering. Annars kommer det uppstå commits där enda skillnaden är vilken indentering som används.
Ansträng dig för att hitta på bra namn på dina variabler och funktioner. Bra namn är:
- Meningsfulla
- Beskriver syftet
- Lätta att läsa och uttala
- Självdokumenterande
- Lagom långa
- Luras inte
Förklaring
Meningsfulla namn betyder något. Ett variabelnamn ska vara "fullt av mening" som beskriver vad dess värde representerar.
Beskriver syftet gör ett namn om man förstår hur värdet ska användas.
Lätta att läsa behöver namnen alltid vara, eftersom den mesta tiden går åt till att läsa kod, inte skriva den.
Lätta att uttala behöver namnen vara så fort man ska diskutera dem med någon annan. Se Rubber Duck Debugging.
Självdokumenterande namn minskar behovet av kommentarer.
Lagom långa - undvik förkortningar. Skriv ut hela ord och var inte rädd för att ha lite längre namn.
let variable = 5; // Dåligt! Meningsfulla namn säger något om sitt innehåll
let value = 5; // Dåligt! Meningslöst namn
let maximumAgeYears = 5; // Bra!
let chosenOption; // Dåligt! Vad är det man väljer mellan?
let chosenTransportation; // Bra! Vi förstår att alternativen representerar färdmedel
let inconspicuousAggregator; // Blä! Svårt att läsa. Försök hitta enklare ord.
let usrMgmt; // Dåligt! Svårt att uttala. Förkortningar är sällan bra.
let userManagement; // Bra! Lätt att läsa och uttala.
// Detta är användarens hemadress
let address; // Kommentaren är nödvändig, eftersom namnet på variabeln är vagt.
// Detta är användarens adress
let homeAddress; // Bättre namn, kommentaren behöver inte säga lika mycket
let userHomeAddress; // Namnet är självdokumenterande, kommentar behövs inte
let hamster = getHamsters()
// Funktionen säger att den hämtar FLERA hamstrar (lägg märke till plural-s)
// Men variabeln säger att den innehåller EN hamster
// Kommer variabeln att innehålla en array eller ett enskilt värde?Ibland har man en känsla av att koden inte är bra, men det kan vara svårt att sätta fingret på vad som är problemet. Några exempel:
- Duplicerad kod
- Mystiska namn
- För korta eller för långa namn
- Lång funktion
- Onödig komplexitet
- För lång kodrad
- Callback hell
Förklaring
Så fort samma kod förekommer på minst två ställen bör du överväga att antingen införa en variabel, en loop eller en funktion.
En mycket vanlig bug är att ändra ett värde, men glömma att ändra det på alla ställen det förekommer. Undvik det genom att använda en variabel. Då ändrar du värdet på bara ett ställe.
let score = 5
...
if( correctAnswer ) { score += 5 }
// Värden som dyker upp utan någon förklaring på det här sättet kallas "magic numbers" eller "magic strings". Undvik!
const correctAnswerPoints = 5
let score = correctAnswerPoints
...
if( correctAnswer ) { score += correctAnswerPoints }
// En bonus är att variabeln är självdokumenterande och hjälper till att förklara vad som händer i koden.Namn ska som sagt vara självdokumenterande. Mystiska eller svårbegripliga namn är ett tecken på att koden är svår att förstå.
Hur lång en funktion bör vara varierar mellan olika programmeringsspråk och beror på vem man frågar. En funktion som är så lång att du inte kan se hela på skärmen utan att scrolla är definitivt för lång. (En del menar att en funktion bör vara högst 5 rader.) När en funktion blir för lång, refaktorera koden och dela upp den i flera funktioner.
Gör inte koden komplicerad i onödan. Börja med den enklast möjliga lösningen. Fungerar inte den, så kan du försöka med en mera avancerad.
Callback hell är vanligt i JavaScript. Det uppstår när man är tvungen att indentera flera gånger. Undvik det genom att skriva om koden. Att använda async-await kan också underlätta.
// Kan du skriva om detta så att koden blir enklare?
if( condition1 ) {
if( condition2 ) {
if( condition3 ) {
// Do stuff
} else {
return
}
} else {
return
}
} else {
return
}Bättre kod
// Bättre kod
if( !condition1 ) {
return
}
if( !condition2 ) {
return
}
if( !condition3 ) {
return
}
// Do stuff-
DRY = Don't Repeat Yourself. Använd variabler och funktioner för att undvika att göra samma sak två gånger.
-
KISS = Keep It Simple Stupid. Ansträng dig för att hålla koden så enkel som möjligt. Enklare är alltid bättre.
-
Lämna koden i bättre skick än du hittade den. Om du går tillbaka in i en kod där du inte varit på ett tag, lägg lite extra tid på att städa i den.
-
Leta alltid efter grundorsaken. Försök att hitta anledningen till att en bug inträffar och åtgärda den. Annars kommer den ofta tillbaka senare i utvecklingen.