En av de mest välfyllda sessionerna jag besökte var Kevlin Henneys Seven Ineffective Coding Habits of Many Programmers. En given publiksucce med den titeln. Som titeln antyder fick vi sju punkter som jag tror de flesta tampas med i olika grad. Without further ado:
Kommentarer
En stor källa till svårläst kod är kommentarerna. Ingen läser dem, de följer sällan med förändringarna i koden och blir därför ännu mer oanvändbara än de var när de skrevs.
Det finns säker branscher och andra grupper som har andra åsikter, men jag tycker att det råder en konsensus kring att kommentarer inte tillför så mycket. Kommentarer kan motiveras där det är verkligt svårt att förstå, men om så är fallet så beror det sällan på svårbegripliga algoritmer utan snarare illa skriven kod. In my opinion.
Unsustainable spacing
(Jag tar gärna emot förslag på översättning)
Programmerare tänker för lite på hur koden ska sättas för att den ska vara läsbar på alla typer av skärmar och upplösningar. Ett sätt att undvika det är att alltid genomföra Code Reviews på en annan dator eller skärm än den som utvecklaren skrivit koden på.
Henney hävdar att det är för mycket tradition och för lite pragmatism i hur koden intendenteras. Vissa sätt är helt enkelt mer läsbara än andra. Han uppmanade oss att titta på koden genom att zoom:a ut. Är den rätt intendenterad kan man se hur allt hänger ihop och dessutom få hjälp med var det är lämpligt att refaktorisera för att få en ännu mer läsbar kod.
Några exempel:
Function foo(var a, var b)
Function foo(var a,
var b);Function foo(
var a,
var b)
{
}
Vilken är mest läsvärd och lätt att underhålla?
Namngivning
Undvik långa namn, de är svårlästa och innebär ofta att du har krånglat till det och behöver försöka hitta något bättre. Undvik ord som är förstörda och inte längre betyder något såsom factory, handler, controller, do, proxy osv.
Gör en termkarta över din källkod för att hitta dina svagheter.
Tänk på vad som ska uppnås, inte vad objektet borde heta och försök att tänka på metoder och egenskapernas namngivning utifrån eftersom det är därifrån de ska anropas (om det inte är rekursiva förstås). Tyvärr skriver vi ofta dem inifrån vilket leder till mer svårbegriplig kod.
Var inte rädd för att överlagra enkla klasser för att öka läsbarheten.
Exempel på lämpliga omskrivningar:
Conditionchecker{bool checkCOndition()}
=>
Condition {IsTrue()}
createConnection() => connect()
Trivia: 326 argument är rekordet för en konstruktor.
Unencapsulated state
Vi måste bli bättre på att paketera och avskärma delarna i ett system från varandra. Tänk på affordance-begreppet när du konstruerar din kod. Den ska vara enkel att anropa.
Mycket punktnotation är ett tecken på att du visar upp för mycket av den underliggande strukturen.
Vad ska jag göra om en vampyr kommer in i mitt hus? Feltänkt. Släpp inte in vampyrerna!
Getters and setters
Get och Set är två av engelskans ord med flest definitioner. Undvik dem.
Uncohesive tests
Många betar av egenskap för egenskap hos ett system. Sluta med det. Testa systemets beteende istället.
Får du också det bara till sex punkter?