10 Måter å unngå bugs i C ++ - dummies

Det er et uheldig faktum at du vil bruke mer tid på å søke etter og fjerne feil enn du vil bruke faktisk å skrive C ++-programmene dine først og fremst. Forslagene her kan hjelpe deg med å minimere antall feil du introduserer i programmene dine for å gjøre programmeringen til en mer fornøyelig opplevelse.

Aktiver alle advarsler og feilmeldinger

Syntaksen til C ++ gir mye feilkontroll. Når kompilatoren møter en konstruksjon som den ikke kan dechifrere, har den ikke annet valg enn å sende ut en melding. Den prøver å synkronisere sikkerhetskopier med kildekoden (noen ganger mindre enn vellykket), men det vil ikke generere en kjørbar. Dette tvinger programmereren til å fikse alle feilmeldinger.

Men når C ++ kommer over en struktur som den kan finne ut, men strukturen lukter i alle fall, genererer C ++ en advarsel. Fordi C ++ er ganske sikker på at det forstår hva du vil, går det videre og lager en kjørbar fil slik at du kan ignorere advarsler hvis du vil. Faktisk, hvis du virkelig ikke vil bli plaget, kan du deaktivere advarsler.

Deaktivere eller på annen måte ignorere advarsler er en utrolig dårlig ide. Det er litt som å koble fra "sjekk motoren" -lyset på bilens dashbord fordi det plager deg. Å ignorere problemet gjør det ikke til å gå vekk.

Vedta en klar og konsistent kodestil

Å skrive C ++-koden i en klar og konsekvent stil forbedrer ikke bare lesbarheten til programmet ditt, men resulterer også i færre kodingsfeil. Denne noe overraskende tilstanden skyldes at hjernen vår bare har en begrenset mengde databehandlingskraft.

Når du leser kode som er rent og pent, og som følger en stil du er kjent med, bruker du svært liten hjernekraft som analyserer syntaksen til C ++-setningene. Dette gir mer hjernens CPU-kraft til å avkode hva programmet prøver å gjøre, og ikke hvordan det gjør det.

En god kodestil lar deg enkelt gjøre følgende:

• Differensiere mellom klassenavn, objektsnavn og funksjonsnavn

• Forstå hva klassen, funksjonen eller objektet brukes til, basert på navnet sitt

• Differensiere preprosessorsymboler fra C ++-symboler (det vil si #definale objekter skal skille seg ut)

• Identifiser blokker av C ++-kode på samme nivå (dette er resultatet av konsistent innrykk)

I I tillegg må du opprette et standardformat for modulhodene dine som gir informasjon om funksjonene eller klassene i hver modul, forfatteren, datoen, versjonen og noe om endringshistorikken.

Alle programmerere involvert i et enkelt prosjekt burde bruke samme kodestil. Et program skrevet i et lappeteppe av forskjellige kodingsstiler er forvirrende og ser uprofesjonelt ut.

Merk koden mens du skriver den

Du kan unngå feil hvis du kommenterer koden mens du skriver den, i stedet for å vente til alt fungerer, og deretter gå tilbake og legg til kommentarer.

Formulering av kommentarer tvinger deg til å utnytte hva det er du prøver å gjøre. Korte kommentarer er opplysende, både når du leser dem senere og når du skriver dem. Skriv kommentarer som om du snakker med en annen, kunnskapsrik programmerer.

Enkelt trinn hver vei i debuggeren minst en gang

Som programmerer må du forstå hva programmet ditt gjør. Det er ikke tilstrekkelig at programmet gir den forventede verdien. Du må forstå alt ditt program gjør. Ingenting gir deg en bedre følelse av hva som skjer under hetten enn single-stepping programmet, og utfører det trinnvis med en god debugger (som den som følger med Code:: Blocks).

Utover det, når du feilsøker et program, trenger du råmateriale for å finne ut noen bizar oppførsel som kan kaste opp når programmet kjører. Ingenting gir deg det materialet bedre enn enkelt-trinn gjennom hver funksjon som det kommer i bruk.

Til slutt, når en funksjon er ferdig og klar til å bli lagt til programmet, må hver logisk bane reist minst en gang. Bugs er mye lettere å finne når du undersøker funksjonen av seg selv, snarere enn etter at den er blitt kastet i potten med resten av funksjonene. Dermed har oppmerksomheten gått på nye programmeringsutfordringer.

Begrense synligheten

Begrense synligheten til klassen internals til verden utenfor er en hjørnestein i objektorientert programmering. Klassen skal være ansvarlig for sin interne tilstand - hvis noe blir skrudd opp i klassen, så er det klassens programmerer feil. Applikasjonsprogrammereren bør bekymre seg for å løse problemet ved hånden.

Spesifikt betyr begrenset sikt at datamedlemmer ikke skal være tilgjengelige utenfor klassen - det vil si at de skal merkes som beskyttet. I tillegg må medlemsfunksjoner som applikasjonsprogramvaren ikke trenger å vite om, også merkes beskyttet. Ikke avslør mer av klassen internals enn nødvendig for å få jobben gjort.

Hold oversikt over buntehukommelse

Å miste bane med buntehukommelse er den vanligste kilden til fatale feil i programmer som er utgitt i feltet - og samtidig det vanskeligste problemet å spore opp og fjerne. (Fordi denne klassen av feil er så vanskelig å finne og fjerne, er den utbredt i programmer du kjøper.) Det kan hende du må kjøre et program i timer før problemer oppstår (avhengig av hvor stor minnelekkingen er).

Som regel bør programmører alltid allokere og frigjøre heapminne på samme nivå. "Hvis et medlem funksjon MyClass:: create () tildeler en blokk med heapminne og returnerer den til den som ringer, så skal det være et medlem MyClass:: release () som returnerer det til bunken.Spesielt bør MyClass:: create () ikke kreve at foreldrefunksjonen slipper ut minnet.

Hvis det er mulig, bør MyClass holde oversikt over slike minnepekere alene og slette dem i destructoren.

Nullpunktspunkter etter at du har slettet hva de peker på

Pass på at du nullstiller poeng etter at de ikke lenger er gyldige. du gjør det ved å tildele dem verdien nullptr. Årsakene til denne handlingen blir tydelige med erfaring: Du kan fortsette å bruke en minneboks som er returnert til bunken og ikke engang kjenner den. Et program kan gå bra 99 prosent av tiden, noe som gjør det svært vanskelig å finne 1 prosent av tilfellene der blokken blir reallokert og programmet ikke fungerer.

Hvis du nullstiller pekere som ikke lenger er gyldige, og du prøver å bruke dem til å lagre en verdi (du kan ikke lagre noe på eller i nærheten av nullstedet), vil programmet ditt krasje umiddelbart. Krasj høres dårlig ut, men det er ikke om det viser et problem. Problemet er der; det er bare et spørsmål om du finner det eller ikke før du setter det i produksjon.

Bruk unntak for å håndtere feil

Unntaksmekanismen i C ++ er utviklet for å håndtere feil på en hensiktsmessig og effektiv måte. Generelt bør du kaste en feilindikator i stedet for å returnere et feilflagg. Den resulterende koden er lettere å skrive, lese og vedlikeholde. Dessuten har andre programmerere kommet til å forvente det, og du vil ikke skuffe dem, ville du?

Begrens bruk av unntak til ekte feil. Det er ikke nødvendig å kaste unntak fra en funksjon som returnerer en "fungerte" indikator hvis dette er en del av hverdagen for den funksjonen.

Erklære destructorer virtuelle

Ikke glem å opprette en destructor for klassen din hvis konstruktøren allokerer ressurser som heapminne som må returneres når objektet når sin ultimate dødsfall. Etter å ha opprettet en destructor, ikke glem å erklære den virtuell.

"Men," sier du, "min klasse arver ikke fra noe, og den er ikke underklasse av en annen klasse. "Ja, men det kan bli en grunnklasse i fremtiden. Med mindre du har noen god grunn til ikke å erklære destruktoren virtuell, så gjør det når du først lager klassen.

Gi en kopi-konstruktør og overbelastet oppdragsoperatør

Hvis klassen din trenger en destructor, trenger den nesten en kopi-konstruktør og en overbelastet oppdragsoperatør. Hvis konstruktøren tildeler ressurser som heapminne, vil standardkopieringskonstruksjon og oppdragsoperatør ikke gjøre noe annet enn å skape kaos ved å generere flere pekere til de samme ressursene.

Når destruktoren for ett av disse objektene blir påkalt, vil det gjenopprette eiendelene. Når destruktoren til den andre kopien kommer sammen, vil den skru opp ting.