10 Måder at undgå fejl i C ++ - dummies

Det er et uheldigt faktum, at du vil bruge mere tid på at søge efter og fjerne fejl, end du vil bruge faktisk at skrive dine C ++-programmer i første omgang. Forslagene her kan hjælpe dig med at minimere antallet af fejl, du introducerer i dine programmer, for at gøre programmeringen til en mere fornøjelig oplevelse.

Aktiver alle advarsler og fejlmeddelelser

Syntetikken i C ++ giver mulighed for en masse fejlkontrol. Når kompilatoren møder en konstruktion, som den ikke kan dechifrere, har den intet andet valg end at sende en besked. Det forsøger at synkronisere sikkerhedskopier med kildekoden (undertiden mindre end med succes), men det genererer ikke en eksekverbar. Dette tvinger programmøren til at rette alle fejlmeddelelser.

Men når C ++ kommer på tværs af en struktur, som den kan finde ud af, men strukturen lugter alligevel, opretter C ++ en advarselsmeddelelse. Fordi C ++ er temmelig sikker på, at det forstår, hvad du vil, går det videre og opretter en eksekverbar fil, så du kan ignorere advarsler, hvis du vil. Faktisk, hvis du virkelig ikke ønsker at blive generet, kan du deaktivere advarsler.

Deaktivering eller på anden måde at ignorere advarsler er en ekstraordinær dårlig idé. Det er lidt som at tage tænd for "Check Engine" -lyset på bilens instrumentbræt, fordi det plager dig. At ignorere problemet gør det ikke muligt at gå væk.

Vedtag en klar og ensartet kodestil

At skrive din C ++ kode i en klar og ensartet stil forbedrer ikke blot læsbarheden af ​​dit program, men det resulterer også i færre kodningsfejl. Denne noget overraskende situation skyldes, at vores hjerner kun har en begrænset mængde computerkraft.

Når du læser kode, der er ren og pæn og følger en stil, du er bekendt med, bruger du meget lidt hjernekraft, der analyserer syntaxen af ​​C ++-sætningerne. Dette giver mere hjerne-CPU-strøm til at afkode, hvad programmet forsøger at gøre, og ikke hvordan det gør det.

En god kodende stil gør det let for dig at gøre følgende:

• Differentier mellem klassenavne, objekternavne og funktionsnavne

• Forstå hvad klassen, funktionen eller objektet bruges til, baseret på navnet

• Differentiate preprocessorsymboler fra C ++-symboler (det vil sige #definerede objekter skal skille sig ud)

• Identificer blokke af C ++-kode på samme niveau (dette er resultatet af ensartet indrykning)

I Desuden skal du oprette et standardformat til dine moduloverskrifter, der indeholder oplysninger om funktioner eller klasser i hvert modul, forfatteren, datoen, versionen og noget om ændringshistorikken.

Alle programmører involveret i et enkelt projekt skal bruge den samme kodestil. Et program skrevet i et lappearbejde med forskellige kodningsstile er forvirrende og ser uprofessionelt ud.

Kommenter koden, mens du skriver den

Du kan undgå fejl, hvis du kommenterer din kode, mens du skriver den, i stedet for at vente, indtil alt fungerer, og derefter gå tilbage og tilføje kommentarer.

Formulering af kommentarer tvinger dig til at gøre rede for, hvad det er, du forsøger at gøre. Korte kommentarer er oplysende, både når du læser dem senere og som du skriver dem. Skriv kommentarer som om du snakker med en anden, kyndig programmør.

Enkeltstræk hver sti i debuggeren mindst en gang

Som programmør skal du forstå, hvad dit program gør. Det er ikke tilstrækkeligt, at programmet udsender den forventede værdi. Du skal forstå alt, hvad dit program gør. Intet giver dig en bedre følelse af hvad der sker under hood'en end single-stepping programmet, og udfører det trin for trin med en god debugger (som den der følger med Code:: Blocks).

Ud over det, når du fejler et program, har du brug for råmateriale til at finde ud af nogle bizarre adfærd, der kan opstå, når programmet kører. Intet giver dig det materiale bedre end single-step gennem hver funktion som det kommer i brug.

Endelig, når en funktion er færdig og klar til at blive tilføjet til programmet, skal hver logisk vej rejst mindst én gang. Bugs er meget nemmere at finde, når du undersøger funktionen i sig selv snarere end efter at den er blevet kastet i puljen med resten af ​​funktionerne - da har din opmærksomhed været på nye programmeringsudfordringer.

Begræns synligheden

Begrænsning af klassens internalsynlighed til omverdenen er en hjørnesten i objektorienteret programmering. Klassen skal være ansvarlig for sin interne tilstand - hvis noget bliver skruet op i klassen, så er det klassens programmørens fejl. Ansøgningsprogrammereren bør bekymre sig om at løse problemet ved hånden.

Specifikt betyder begrænset synlighed, at data medlemmer ikke skal være tilgængelige uden for klassen - det vil sige, de skal markeres som beskyttet. Desuden skal medlemsfunktioner, som applikationssoftwaren ikke behøver at vide om, også markeres beskyttet. Udsæt ikke mere af klassens internere end nødvendigt for at få arbejdet færdigt.

Hold øje med bunkehukommelse

At tabe bunkehukommelse er den mest almindelige kilde til fatale fejl i programmer, der er udgivet i feltet - og samtidig det sværeste problem at spore og fjerne. (Fordi denne klasse af fejl er så svært at finde og fjerne, er den udbredt i programmer, som du køber.) Du må muligvis køre et program i timer, før problemerne opstår (afhængigt af hvor stor hukommelseslækage er).

Programmerne skal som hovedregel altid allokere og frigive hukommelse på samme niveau. "Hvis et medlem funktion MyClass:: create () tildeler en blok af bunkehukommelse og returnerer den til opkalderen, så skal der være et medlem MyClass:: release (), der returnerer det til bunken.Specifikt, MyClass:: create () skal ikke kræve, at moderfunktionen frigiver hukommelsen.

Hvis det overhovedet er muligt, skal MyClass holde styr på sådanne hukommelsespegere alene og slette dem i destructoren.

Nul ud pointers efter at have slettet hvad de peger på

Sørg for, at du nulter pointers, når de ikke længere er gyldige; det gør du ved at tildele dem værdien nullptr. Årsagerne til denne handling bliver tydelige med erfaring: Du kan fortsætte med at bruge en hukommelsesblok, der er returneret til bunken og ikke engang ved det. Et program kan løbe fint 99 procent af tiden, hvilket gør det meget svært at finde de 1 procent af tilfælde, hvor blokken bliver reallokeret, og programmet virker ikke.

Hvis du sletter nulpegerne, der ikke længere er gyldige, og du forsøger at bruge dem til at gemme en værdi (du kan ikke gemme noget ved eller nær nulstedet), vil dit program straks gå ned. Krasning lyder dårligt, men det er ikke, hvis det udsætter et problem. Problemet er der; det er bare et spørgsmål om, om du finder det eller ej, før du sætter det i produktion.

Brug undtagelser til at håndtere fejl

Undtagelsesmekanismen i C ++ er designet til at håndtere fejl bekvemt og effektivt. Generelt skal du kaste en fejlindikator i stedet for at returnere et fejlflag. Den resulterende kode er lettere at skrive, læse og vedligeholde. Derudover har andre programmører kommet til at forvente det, og du vil ikke skuffe dem, ville du?

Begræns din brug af undtagelser til ægte fejl. Det er ikke nødvendigt at kaste en undtagelse fra en funktion, der returnerer en "fungerede" indikator, hvis dette er en del af hverdagen for den funktion.

Erklære destructorer virtuelle

Glem ikke at oprette en destructor til din klasse, hvis konstruktøren tildeler ressourcer som heaphukommelse, der skal returneres, når objektet når sin ultimative død. Efter at have oprettet en destructor, glem ikke at erklære det virtuelt.

"Men," siger du, "min klasse arver ikke fra noget, og den er ikke underklasse af en anden klasse. "Ja, men det kunne blive en base klasse i fremtiden. Medmindre du har en god grund til ikke at erklære destruktoren virtuel, så gør det, når du først laver klassen.

Giv en kopikonstruktør og overbelastet tildelingsoperatør

Hvis din klasse har brug for en destructor, har det næsten sikkert en kopikonstruktør og en overbelastet opgaveoperatør. Hvis din konstruktør tildeler ressourcer som heaphukommelse, vil standardkopieringskonstruktør og opgaveoperatør ikke gøre andet end skabe kaos ved at generere flere pointers til de samme ressourcer.

Når destruktoren til et af disse objekter er påberåbt, vil det genoprette aktiverne. Når destruktoren til den anden kopi kommer sammen, vil den skrue op.