Programmera utan buggar

Hur lär man sig programmera utan att få några buggar? Det gör mig vansinnig att man ska få sitta lika länge till och debugga efter att man har kodat för att få skiten att fungera! Speciellt om man har tidspress på sig.

Köp/läs "Writing Solid Code" av Steve Maguire. Mycket inspirerande och lärorik, låt dig inte luras av att den är utgiven på Microsofts förlag.

Den som det visste. Då skulle man bli rik.

Det är ju enkelt. Det är bara att göra rätt från början.



Seriöst.

Det GÅR INTE att göra 100% buggfri kod. Utom för de mest triviala programmen.

Visst, vissa felkällor går att få bort:

1. Skrivfel. Man skriver komma i stället för punkt. Plus i stället för minus. A i stället för B. Sånt går nog att rensa bort. Ofta hjälper ju kompilatorn/tolken till där.

2. Tankefel. Man har tänkt fel när man löst uppgiften. Sånt går att städa bort med testningar och interaktion med de som skall använda programmet.

Men - sen kommer det jävliga:

3. Tredjepartsfel. Dvs det är fel i ens kompilator/tolk. Nån drivrutin för något helt annat, t ex skrivare - har ställt till det så att just ditt program - som inte har med skrivare alls att göra - kraschar. Sånt kan driva en till vansinne eftersom man får bygga om ett helt ok program för att ta hänsyn till en annan slapptask till programmerare.

4. Synergifel. Det är tyvärr inte så att femtio korrekta moduler som sätts samman blir ett korrekt system. De kan vara helt rätt var och en för sej, men den som designat hela systemet har tänkt fel. Eller inte insett hur de skall arbeta ihop.

Så. Nej, nöj dej med att det fungerar ok. Buggarna - de rättas i nästa version ...

Det krävs träning och helst förberedelser. Om du har tidspress försämrar det förutsättningarna. Med mycket träning kommer du hela tiden hålla flera saker i huvudet och tänka framåt, vilket hjälper mycket. Om du har förberett dig genom att tänka ut eller att du skrivit upp hur programmet ska fungera i detalj så hjälper det med.

Som sagts tidigare kommer du aldrig kunna skriva program helt utan buggar. Jag brukar skilja mellan två sorters buggar. Den ena sorten (1) är den som måste bort för att programmet alls ska fungera, den andra sorten är den som finns fastän programmet ser ut att fungera (2).

(2) kommer du aldrig kunna få bort helt ur annat än jättesmå program.

(1) måste du ju uppenbarligen få bort. Skriver man hela programmet utan att testa det så blir det en förfärlig massa buggletande efteråt. Dessutom är det buggletandet extra jobbigt eftersom man i det skedet kanske har dålig koll på hur programmet egentligen fungerar och därför inte kan gå direkt på den lilla del där felet finns. Därför är det bättre att testa små delar av programmet löpande under tiden man programmerar. Så fort du skrivit en kodsnutt så bör du testa att just den kodsnutten gör vad du tror den gör. Är det komplicerad lågnivåprogrammering kanske du bara kan skriva 5 rader i taget utan att testa. Är det mer rutinmässig programmering kanske du kan skriva mycket mer än så mellan varje test.

Det ligger en hel i det som Ruskiga bussen skriver.

Att programmera utan att det blir buggar går inte så istället gäller att ha en metodik att minimera antalet och försöka att hitta dem så tidigt som möjligt.

Du kanske skulle kolla in det här med TDD, Test Driven Design, för att få lite input på att få en rationellare process. Om du arbetar i Visual Studio och programmerare i C# så kanske programvaran Nunit (www.nunit.org) är av intresse. Jag tycker den är kanon för testning av min kod.

Ja, det ligger nog en del i det du säger att testa koden direkt efter att man bara har skrivit lite till i det. En gång skule jag implementera en heap i mitt program (jobade i texteditorn i linux och kompilerade med g++ i terminalen, så inget vidare IDE heller antar jag). Jag visste inte hur jag skulle testa riktigt om mina metoder för heapen fungerade, så det fick jag se när jag hade skrivit färdigt all kod, och märkte att det gjorde de inte. Jag satt ett bra tag med att försöka få bort alla buggar, men lyckades aldrig. Bland annat upptäckte jag efter en timmas debuging att jag hade råkat skriva = istället för == på ett ställe, vilket är fruktansvärt.

Det är därför man använder -Wall, dvs
blir

Först två citat som säger mer än vad jag kan säga:

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
- Brian W. Kernighan


"* Every program contains at least one error
* Every program can be made shorter by reducing the code by at least one line
Therefore, by induction, we see that:
- Every program can be reduced to one line of code that doesn’t work"


Det är dock teoretiskt möjligt att skriva bugfri kod men det kräver kunskap och extremt mkt merarbete och ändå kan det vara svårt.

De två huvudsakliga metoderna för att åstadkomma det (bortsett från design, design, design):
* Formellt bevisa koden
* Testa varje möjlig väg genom koden och varje möjligt invärde

Båda ovanstående metoder är utopier. Knuth har en berömd kommentar om formellt bevisad kod:
"Beware of bugs in the above code; I have only proved it correct, not tried it"

Metodiken som man bör använda är dock att skriva test-fall hela tiden så man kan kontinuerligt testa varje funktion/metod medan man skriver och även efter när det sätts samman i sin helhet. Att se över vilka antaganden som görs och dokumentera, följa och sedan visa att de gäller när du implementerat koden.

Det finns dock språk som gör det möjligt att skriva så gott som buggfri kod men de är inte alltid lämpade för riktiga system. Logikspråket Prolog och funktionsspråket Haskell är t ex båda väl lämpade för att skriva, bevisa och testa koden och jag vet att många använder sig av t ex Haskell för att matematiskt bevisa alla antaganden som tagits.

Rent praktiskt, när man kodar själv och inte har för starka krav på korrekthet så är väl den bästa regeln att koda så det är lättläst och enkelt att förstå, kommentera och dokumentera antaganden, testa kontinuerligt och använd de hjälpmedel som finns.
Tips på bra hjälpmedel är t ex att slå på alla potentiellt relevanta varningar i din kompilator[1], använda run-time checkers (valgrind!!!), om du har tillgång till det så använd programvara för statisk kodanalys.

För projekt i C så rekommenderar jag dig att läsa delar av koden samt designen till vsftpd eller någon av D J Bernsteins programvaror för inspiration av hur man skriver enkel, lättläst och idiotsäker kod.

[1] just nu har jag så gott som alltid följande påslaget när jag kodar C (kräver modern version av gcc):
-Wall -Wextra -Wshadow -Wwrite-strings -Wsign-compare -Wfloat-equal -Wconversion -Wmissing-noreturn -Wbad-function-cast -Wswitch-default -Wmissing-prototypes -Winline -Wredundant-decls

Två "enkla" metoder att höja kvalitén på sin kod är att arbeta mha parprogrammering och automatiska enhetstester. Parprogrammering ger som regel bättre design och fler tankefel/buggar upptäcks på ett tidigt stadium. Automatiska enhetstester hjälper till att hålla koden buggfri/fungerande även i framtiden. Som någon skrev så är TDD en bra metodik som inte i kräver parprogrammering för att fungera men som kommer till sin fulla rätt först då man kombinerar dessa två arbetssätt.

Mvh

Tyvärr känner jag varken till parprogrammering eller automatiska enhetstester, men eftersom parprogrammering finns på susning.nu var det ganska enkelt att hitta så nu vet jag vad det betyder. Jag har dock ingen att samarbeta med så jag får väl vara min egen partner.