Vi som arbetar mer eller mindre aktivt med kod uppskattar förstås när koden, och systemet som det ingår i, är välstrukturerad. Det finns mycket litteratur på området, Robert C. Martins Clean Code och Clean Architecture är standardverk som man behöver läsa, liksom Refactoring av Martin Fowler.
Flera tips är förstås SOLID, en förkortning av några enkla(?) regler för bra objekt-orienterad design som i stor utsträckning också kan omtolkas för att passa även icke-objekt-orienterad kod. Bra kod luktar inte illa så Code Smells är också bra tips om vad man skall undvika. Något jag ofta gör är att jag upptäcker en kod-lukt och hittar en refaktorering som hjälper mot den.
Och det finns säkert många fler tips. N.B. jag har också sett programmerare gått bärsärk i ambitionen att få så ren kod som möjligt, lagom är bäst. Sträva alltid efter att lämna koden lite bättre än du fann den (scout-regeln).
En "regel" som är lika enkel som effektiv är "Law of Demeter". Ett par grundläggande egenskaper vi strävar efter i bra kod är isolering, abstration och låg koppling. "Law of Demeter" funkar väldigt bra som riktlinje här.
Ett beroende som kopplar enheter tätare ihop än nödvändigt är att en "klient" behöver veta vilka fält som finns t.ex i en klass eller struktur. Det gör ju att om man ändrar dessa fält så påverkar det all klienter.
Demeters lag har inget med guden Demeter att göra utan kommer från ett projekt som hade "lagen" som en av sina designregler. "Lagen" säger
A method can only access either locally-instantiated variables, parameters passed in, or instance variables,
Kanske inte så uppenbart, men i princip betyder det att en funktion/metod inte får navigera vidare ner i strukturer. Och ett enkelt sätt att uttrycka det är
Bara en punkt i varje kodrad.
Och det är klart att "punkt" bara används i vissa programmeringsspråk, men du förstås säkert vad det skall tolkas till i just ditt programmeringsspråk.
Tack till Corey Haines som i sin skrift Understanding the Four Rules of Simple Design inspirerade till denna blogpost.
