10 Manieren om bugs te vermijden in C ++ - dummies

Het is een ongelukkig feit dat u meer tijd zult besteden aan het zoeken en verwijderen van fouten dan dat u in de eerste plaats daadwerkelijk aan het schrijven bent over uw C ++ -programma's. De suggesties hier kunnen u helpen het aantal fouten dat u in uw programma's introduceert te minimaliseren om het programmeren tot een aangenamere ervaring te maken.

Schakel alle waarschuwingen en foutmeldingen in

De syntaxis van C ++ zorgt voor veel foutcontroles. Wanneer de compiler een constructie tegenkomt die hij gewoon niet kan ontcijferen, heeft hij geen andere keuze dan een bericht uit te voeren. Het probeert te synchroniseren met de broncode (soms minder dan met succes), maar het genereert geen uitvoerbaar bestand. Dit dwingt de programmeur om alle foutmeldingen te herstellen.

Wanneer C ++ echter een structuur tegenkomt die het kan achterhalen, maar de structuur toch smaakt, probeert C ++ een waarschuwingsbericht te genereren. Omdat C ++ er vrij zeker van is dat het begrijpt wat je wilt, gaat het door en maakt het een uitvoerbaar bestand zodat je waarschuwingen kunt negeren als je dat wilt. Als je echt geen zin hebt, kun je waarschuwingen uitschakelen.

Waarschuwingen uitschakelen of anderszins negeren is een buitengewoon slecht idee. Het lijkt een beetje op het loskoppelen van het "check engine" -lampje op het dashboard van je auto, omdat het je stoort. Het negeren van het probleem laat het niet verdwijnen.

Adopteer een duidelijke en consistente coderingsstijl

Het schrijven van uw C ++-code in een duidelijke en consistente stijl verbetert niet alleen de leesbaarheid van uw programma, maar resulteert ook in minder coderingsfouten. Deze enigszins verrassende situatie komt voort uit het feit dat onze hersenen maar een beperkte hoeveelheid rekenkracht hebben.

Wanneer u code leest die netjes en overzichtelijk is en een stijl volgt die u kent, besteedt u heel weinig hersencapaciteit aan het parseren van de syntaxis van de C ++ - instructies. Dit laat meer CPU-kracht van de hersenen over om te decoderen wat het programma probeert te doen en niet hoe het het doet.

Met een goede codeerstijl kunt u het volgende gemakkelijk doen:

Onderscheid maken tussen klassenamen, objectnamen en functienamen
Begrijpen wat de klasse, functie of object wordt gebruikt voor, op basis van de naam
Differentiëren preprocessor-symbolen van C ++ -symbolen (dat wil zeggen, #define-objecten moeten opvallen)
Identificeer blokken van C ++-code op hetzelfde niveau (dit is het resultaat van consistente inspringing)

Bovendien moet u een standaardindeling voor uw modulekoppen maken die informatie biedt over de functies of klassen in elke module, de auteur, de datum, de versie en iets over de wijzigingsgeschiedenis.

Alle programmeurs die bij een enkel project zijn betrokken, moeten dezelfde coderingsstijl gebruiken. Een programma geschreven in een lappendeken van verschillende codeerstijlen is verwarrend en ziet er onprofessioneel uit.

Reageer op de code terwijl u deze schrijft

U kunt fouten voorkomen als u uw code becommentarieert terwijl u deze schrijft, in plaats van te wachten tot alles werkt en dan terug te gaan en opmerkingen toe te voegen.

Het formuleren van opmerkingen dwingt je om de balans op te maken van wat je probeert te doen. Korte opmerkingen zijn verhelderend, zowel wanneer u ze later leest als terwijl u ze schrijft. Schrijf opmerkingen alsof u met een andere, deskundige programmeur praat.

Eén stap per pad in de foutopsporing ten minste één keer

Als programmeur moet u begrijpen wat uw programma aan het doen is. Het is niet voldoende dat het programma de verwachte waarde uitvoert. Je moet alles begrijpen wat je programma aan het doen is. Niets geeft je een beter gevoel voor wat er onder de motorkap gebeurt dan single-stepping , en voert het stap voor stap uit met een goede debugger (zoals degene die geleverd wordt met Code:: Blocks).

Bovendien, terwijl u een programma zuivert, hebt u grondstof nodig om een of ander bizar gedrag te achterhalen dat tijdens het uitvoeren van het programma kan optreden. Niets geeft u dat materiaal beter dan één stap door elke functie als deze in dienst komt.

Tot slot, wanneer een functie is voltooid en gereed is om aan het programma te worden toegevoegd, moet elk logisch pad ten minste één keer worden afgelegd. Bugs zijn veel gemakkelijker te vinden wanneer je de functie zelf onderzoekt in plaats van nadat deze met de rest van de functies in de pot is geworpen - tegen die tijd is je aandacht verlegd naar nieuwe programmeeruitdagingen.

Beperk de zichtbaarheid

Beperk de zichtbaarheid van klasse-internals tot de buitenwereld is een hoeksteen van objectgeoriënteerd programmeren. De klasse zou verantwoordelijk moeten zijn voor zijn interne toestand - als iets in de klas wordt verknoeid, dan is het de schuld van de klassenprogrammeur. De applicatieprogrammeur moet zich zorgen maken over het oplossen van het probleem.

Concreet betekent beperkt zicht dat gegevensleden niet buiten de klasse toegankelijk moeten zijn, dat wil zeggen dat ze als beschermd moeten worden gemarkeerd. Bovendien moeten lidfuncties die de toepassingssoftware niet moet kennen, ook worden gemarkeerd als beschermd. Stel niet meer van de interne classals bloot dan nodig is om de klus te klaren.

Heap-geheugen bijhouden

Heap-geheugen kwijtraken is de meest voorkomende bron van fatale fouten in programma's die in het veld zijn vrijgegeven - en tegelijkertijd het moeilijkste probleem om op te sporen en te verwijderen. (Omdat deze klasse van fouten zo moeilijk te vinden en te verwijderen is, komt deze vaak voor in programma's die u koopt.) Misschien moet u een programma uren draaien voordat problemen optreden (afhankelijk van hoe groot het geheugenlek is).

Als algemene regel geldt dat programmeurs altijd het geheugen op hetzelfde "niveau" moeten toewijzen en vrijgeven. "Als een lid MyClass:: create () gebruikt, wijst het een blok heapgeheugen toe en geeft het terug aan de beller, dan moet er een lid MyClass:: release () zijn dat het naar de heap retourneert.Meer specifiek, MyClass:: create () vereist niet dat de parent-functie het geheugen vrijgeeft.

MyClass moet, indien mogelijk, dergelijke geheugenaanwijzingen alleen bijhouden en verwijderen in de destructor.

Geen verwijzingen naar verwijzingen na het verwijderen van de items waarnaar ze verwijzen

zorg ervoor dat u wijzingen uitsluit die niet meer geldig zijn; Dit doet u door ze de waarde nullptr toe te wijzen. De redenen voor deze actie worden duidelijk met ervaring: je kunt een geheugenblok blijven gebruiken dat naar de stapel is teruggestuurd en het niet eens kent. Een programma kan 99 procent van de tijd draaien, waardoor het erg moeilijk is om de 1 procent van de gevallen te vinden waarin het blok opnieuw toegewezen wordt en het programma niet werkt.

Als u wijzers die niet langer geldig zijn, opheft en probeert deze te gebruiken om een waarde op te slaan (u kunt niets opslaan op of nabij de lege locatie), zal uw programma onmiddellijk crashen. Crashen klinkt slecht, maar het is niet als het een probleem blootstelt. Het probleem is er; het is slechts een kwestie van of je het vindt of niet voordat je het in productie gaat nemen.

Gebruik uitzonderingen om fouten af te handelen

Het uitzonderingsmechanisme in C ++ is ontworpen om fouten gemakkelijk en efficiënt af te handelen. Over het algemeen moet u een foutindicator gebruiken in plaats van een foutmarkering te retourneren. De resulterende code is gemakkelijker te schrijven, lezen en onderhouden. Trouwens, andere programmeurs zijn het gaan verwachten, en je wilt ze niet teleurstellen, toch?

Beperk uw gebruik van uitzonderingen tot echte fouten. Het is niet nodig om een uitzondering te maken van een functie die een "niet werkt" -indicator retourneert als dit voor die functie deel uitmaakt van het dagelijks leven.

Decenteer destructors virtueel

Vergeet niet om een destructor voor uw klasse te maken als de constructor bronnen toewijst, zoals het heap-geheugen dat moet worden geretourneerd wanneer het object zijn uiteindelijke ondergang bereikt. Nadat je een destructor hebt gemaakt, vergeet dan niet om hem virtueel te verklaren.

"Maar," zegt u, "mijn klas neemt niets over en wordt niet door een andere klasse ondergebracht. "Ja, maar kan in de toekomst een basisklasse worden. Tenzij u een goede reden heeft om de destructor niet virtueel te declareren, doe dit dan wanneer u de klasse voor het eerst maakt.

Geef een kopieerconstructor en een overbelaste toewijzingsoperator

Als uw klasse een destructor nodig heeft, heeft deze bijna zeker een copy-constructor en een overbelaste toewijzingsoperator nodig. Als uw constructor bronnen zoals Heap-geheugen toewijst, zullen de standaard-copy-constructor en toewijzingsoperator niets anders doen dan ravage aanrichten door meerdere aanwijzers naar dezelfde bronnen te genereren.

Wanneer de destructor voor een van deze objecten wordt aangeroepen, worden de items hersteld. Wanneer de destructor voor de andere kopie langskomt, zal het dingen verpesten.