1. Commentarieer zoveel mogelijk blokken code uit, tot je de fout nauwkeurig kan lokaliseren. Veel voorkomende oorzaken: sluitende accolades waar er openende moeten staan (is het lettertype van je editor groot genoeg?); of misschien heb je de hoofding van de implementatie van een lidfunctie gecopiëerd naar de interface, zonder de accolade te vervangen door een puntkomma (valt het laatste woord van je lijn geregeld buiten leesbereik? Doe daar iets aan!).
2. Een hele rits foutmeldingen waar je er hoogstens enkele verwachtte? Probeer de eerste foutmelding op te lossen; de rest verdwijnt dan misschien vanzelf.
3. Lees de foutmelding eerst zelf zeer grondig; daaruit haal je al heel wat (of minstens een hint in welke richting je moet zoeken). Schept dit geen duidelijkheid, knip dan de niet-code gebonden delen van een foutmelding, en zoek op het net naar een tutorial en/of discussieforum die daarover iets kunnen vertellen. (Let op: wees wel kritisch bij het raadplegen van fora.)

1. Gebruik de debugger; die is daarvoor gemaakt! Je kan op die manier lokale variabelen en expressies volgen (locals, watches,...).
   Let wel: weet je wat je verwacht te vinden? Kan je de inhoud van een gebruikte container volgen, zodat je die kan vergelijken met je verwachtingen?
2. Zoek je liever niet lineair (bij de debugger moet je er constant je aandacht bijhouden!), maar verkies je binair zoeken, laat je programma dan tussentijds voldoende uitschrijven.
   Let wel: dit vervuilt je code nogal. Het minste wat je kan doen, is de "cout<<"-opdracht mijden, en de "cerr<<"-opdracht gebruiken. Dat commentarieert makkelijker uit. Introduceer de "operator<<" voor alle klassen die je (tussentijds) wil uitschrijven. (Haal dat weer weg bij oplevering, als je gebruiker hier geen uitstaans mee heeft!!) Heb je in je lussen voldoende uitgeschreven, dan kan je nadien makkelijk opzoeken tot waar het programma nog wel doet wat er verwacht wordt, en waar het mis begint te lopen.
3. Test je oplossing uit op EENVOUDIGE EN CONTROLEERBARE GEGEVENS, zeker niet random gegenereerd (zo kan je o.a. geen speciale gevallen onderzoeken)! En werk met tabellen van werkbare grootte (kan de hele tabelinhoud op 1 lijntje?).
4. Zie je het nog niet? Duik dieper in je code! Voorbeeld: gebruik eerst potlood en gom om de METHODE van insertion sort toe te passen op een gegeven tabel. Daarna gebruik je potlood en gom om de CODE die je schreef toe te passen op diezelfde tabel. Zo voel je vanzelf wanneer de code bewegingen voorschrijft die niet stroken met het oorspronkelijke idee van insertion sort.

1. Geeft het programma foutmeldingen ná het doorlopen van alle regels code? Kijk eens na wat je destructor doet. Laat de destructor een boodschap uitschrijven vlak voor én vlak na delete [] tab (of gelijkaardige regels code). Veel voorkomende fout: je probeert met de code delete [] p het geheugen waarnaar p verwijst vrij te geven, terwijl dit geheugen al vrijgegeven is door voorgaande aanroepen van een of andere destructor.
2. Loopt het soms wel, soms niet? Wat met je pointers; ben je zeker dat ze goed geïnitialiseerd werden? Lopen je indices zeker niet uit de tabel / vector? Gebruik "assert(...);" om dit overal na te gaan.

Gouden tip

...