fredag 6 februari 2009

G1 - G5

Då fortsätter vi ... många små regler kvar... men nu är det G1 till G5 som gäller.

G1: Flera språk i samma fil
Det finns en anledning till att framework som Wicket och andra jobbar hårt på att inte blanda html och java utan att de som är bra på respektive sak kan jobba med sin sak utan att bli störda av sådant som för dem är irrelavant.

G2: Förväntat beetende är inte implementerat
Tänk er följande metodsignatur:

public int dayToString(String day)

Denna metod översätter texten "monday" till 1. Fundera nu på vilka textsträngar ni skulle förvänta er att metoden kan tolka. Visst är det så att vi förväntar oss att metoden ska kunna tolka resten av veckodagarna? Är det så att vi förväntar oss att en sådan metod ska kunna olika case som MONDAY och monday eller kanske till och med förkortningar? Vad mer borde vi kunna förvänta oss av metoden? Allt detta ni kan förvänta er borde ni också implementera. Om den som ska använda metoden inte får det resultat den förväntar sig (inom rimliga gränser naturligtvis) så kommer personen ifråga att börja fundera på om koden faktisk gör som han/hon förväntar sig i något fall.

G3: Felaktigt beteende vid gränser (boundaries, cornercases)
Det låter självklart så att koden ska göra rätt i alla sammanhang. Men det är också väldigt enkelt att glömma bort att som programmerare glömma bort, eller vid stress "glömma bort" att faktiskt lägga tid på att försäkra sig om att koden faktiskt gör rätt om något annat data än det normala. Även om metoden gör rätt i 10 000 fall så är inte koden rätt förrän alla möjliga utfall är korrekta.

G4: Borttagna säkerhets funktioner
Säkerhet är nästan alltid i vägen så är det. Men oftast finns det en anledning till att de finns där i första rummet. Att strunta i dem är i bästa fall dumdristigt. Glöm inte att säkerhet är mycket mer än bara inloggningar. Kompileringsvarningar tex upplyser om att du kan ha ett problem snart. Varningar om att ett program inte hittade sin konfigurationsfil och därför föll tillbaka på defaultvärden innebär att när det väl kommer en konfigurationsfil kan det få stora effekter på ditt program.

G5: Duplicering
Don't repet yourself (dry), Once and only once. Kärt barn har många namn. Allt går ut på att om man har kod som gör samma sak på två ställen så är det mer än dubbelt så svårt att underhålla koden och det blir lätt att få sin applikation att uppföra sig okonsekvent där vissa funktioner ibland fungerar och ibland inte fungerar berorende att vissa kopior har ändrats och vissa inte. Att vara nogrann med att söka efter existerande funktionallitet räcker långt men om du ska vara seriös skaffar du ett verktyg (inställt på högsta möjliga känslighet) och börjar åtgärda de värsta problemen och forsätter tills hela kodbasen är fri från dupliering. Ibland måste man skriva om koden till att tex använda Template method eller Strategy pattern för de fall där en metod återkommer i koden med små förändringar. Ibland måste man fundera på om man kanske ska byta ut if/else och switch mot polymorfism (don't ask, tell)

Inga kommentarer:

Skicka en kommentar