Reflector og Code Complete – avav…
Har lige læst Code Complete igennem. Det er en bog med en speciel tilgang til kodning. Den har valgt en indgangsvinkel med gode råd til hvordan man bør håndtere kodning – både generelt og meget specifikt, og forfatteren har valgt at tage en analytisk og statistisk tilgang til materialet. I parentes bemærket, jeg tror ikke, jeg tidligere har set en bog med så mange kildehenvisninger…
Hvorom alting er, er det en rigtig god bog at få forstand af. Der var ikke så mange ting, man kan anvende direkte – forfatteren har bevidst valgt at gøre eksemplerne så generelle som muligt, og skifter derfor mellem flere forskellige programmeringssprog. Det er samtidig en lidt ældre bog, hvilket gør en del af eksemplerne lidt utidssvarende. Det der fanger derimod, er måden tingene bliver forklaret på. Mange ting er underbygget af større undersøgelser af hvordan det rent faktisk står til ude i den virkelige verden. Godt nok i slutningen af 90′erne, men der er ikke meget der tyder på at det har ændret sig voldsomt siden.
Efter at have læst den fra start til slut, fik jeg en ide – jeg har i længere tid haft en mistanke om at det tredje parts kontrol-library vi bruger til vores booking applikation kunne være noget værre slamkode – og jeg havde downloadet Reflector for noget tid siden, men var ikke rigtig blevet fortrolig med det. Når software opfører sig ‘mistænksomt’ og hvor man skal lave underlige omveje for at få ting til at virke – og standard objekter er forkastet for en ‘hjemmebrygget’ løsning, tændes en række advarselslamper. Så med ærmerne smøget godt op til albuerne kastede jeg mig ud i at kigge noget kode (Reflector er fantastisk til at kigge ‘under hjelmen’ på tredje parts værktøjer med dens ‘dissassemble’-funktion) og så sammenligne det med anbefalingerne fra Code Complete. Lad os sige det sådan her… det så ikke godt ud…
Jeg har ikke selv brugt goto siden de glade C64-dage… som sådan ikke noget religiøst, men jeg synes min kode blev svær at følge – og især efter jeg fik en god debugger imellem hænderne blev jeg opmærksom på de problemer goto kan skabe med hensyn til klarhed i kode. Uden at ville starte en religionskrig, kan goto ofte være et tegn på at logikken er ved at løbe ud sammen med badevandet. Goto er en ting, men når man så anvender rekursive goto’s (if(x == 2) {x = 3; goto “label01″; -> og label01 er så et stykke før dette kald, så koden bliver kørt igen… og igen… og igen…), så begynder det at lugte… grimt.
Jeg er klar over at den version jeg har testet på er den gratis version – og at comments derfor er rykket ud – og variabelnavne højst sandsynligt er udskiftet med generiske for at afsløre så lidt som muligt… men hold da op for en gang goto-slamkode – metoderne var i gennemsnit omkring 90 linjers kode – og i snit omkring 15 gotos i hver. Jeg prøvede efterfølgende at sammenligne den med konkurrenten – og resultatet på det hele er… at vi højst sandsynligt har valgt den forkerte hest at satse på.