10 Sätt att undvika fel i C ++ - dummies

Det är ett olyckligt faktum att du kommer att spendera mer tid på att leta efter och ta bort buggar än du kommer att spendera faktiskt att skriva dina C ++-program i första hand. Förslagen här kan hjälpa dig att minimera antalet fel du introducerar i dina program för att göra programmeringen till en mer njutbar upplevelse.

Aktivera alla varningar och felmeddelanden

Synkroniseringen av C ++ möjliggör en hel del felkontroll. När kompilatorn möter en konstruktion som den inte kan dechiffrera, har den inget annat val än att skriva ut ett meddelande. Det försöker synkronisera säkerhetskopiering med källkoden (ibland mindre än framgångsrikt), men det kommer inte att generera en körbar. Detta tvingar programmeraren att fixa alla felmeddelanden.

Men när C ++ kommer över en struktur som den kan räkna ut men strukturen lukter i alla fall, genererar C ++ ett varningsmeddelande. Eftersom C ++ är ganska säker på att det förstår vad du vill, går det vidare och skapar en körbar fil så att du kan ignorera varningar om du vill. Faktum är att om du verkligen inte vill vara störd kan du inaktivera varningar.

Att inaktivera eller på annat sätt ignorera varningar är en utomordentligt dålig idé. Det är lite som att koppla från "Check Engine" -ljuset på bilens instrumentpanel eftersom det stör dig. Att ignorera problemet gör det inte att gå iväg.

Antag en tydlig och konsekvent kodningsstil

Att skriva din C ++-kod i en tydlig och konsekvent stil förstärker inte bara läsbarheten för ditt program utan resulterar också i färre kodningsfel. Detta något överraskande tillstånd beror på det faktum att våra hjärnor har en begränsad mängd datorkraft.

När du läser kod som är rent och snyggt och det följer en stil du känner till, spenderar du väldigt lite hjärnkraft som analyserar syntaxen i C ++-uttalandena. Detta låter mer hjärnens CPU-ström att avkoda vad programmet försöker göra och inte hur det gör det.

Med en bra kodningssätt kan du enkelt göra följande:

• Skill mellan klassnamn, objektnamn och funktionsnamn

• Förstå vad klassen, funktionen eller objektet används för, baserat på dess namn

• Differentiera preprocessorsymboler från C ++-symboler (det vill säga #define-objekt ska sticka ut)

• Identifiera block av C ++-kod på samma nivå (detta är resultatet av konsekvent indragning)

I Dessutom måste du skapa ett standardformat för dina modulhuvuden som ger information om funktionerna eller klasserna i varje modul, författaren, datumet, versionen och något om ändringshistoriken.

Alla programmerare som är inblandade i ett enda projekt ska använda samma kodningsstil. Ett program som skrivs i ett lapptäcke av olika kodningsstilar är förvirrande och ser oprofessionellt ut.

Kommentera koden medan du skriver den

Du kan undvika fel om du kommenterar koden medan du skriver den, istället för att vänta tills allt fungerar och sedan gå tillbaka och lägga till kommentarer.

Formulera kommentarer tvingar dig att ta reda på vad det är du försöker göra. Korta kommentarer är upplysande, både när du läser dem senare och när du skriver dem. Skriv kommentarer som om du pratar med en annan, kunnig programmerare.

Enkelt steg varje sökväg i debugger minst en gång

Som programmerare måste du förstå vad ditt program gör. Det är inte tillräckligt att programmet matar ut det förväntade värdet. Du måste förstå allt ditt program gör. Ingenting ger dig en bättre känsla för vad som händer under huven än single-step programmet, genom att göra det steg för steg med en bra debugger (som den som kommer med Code:: Blocks).

Utöver det, när du felsöker ett program behöver du råmaterial för att räkna ut lite bisarrt beteende som kan uppstå när programmet körs. Ingenting ger dig det materialet bättre än att stega genom varje funktion när det kommer i bruk.

När en funktion är färdig och redo att läggas till programmet måste varje logisk väg resta minst en gång. Buggar är mycket lättare att hitta när du undersöker funktionen själv i stället för efter att den har kastats i grytan med resten av funktionerna - då har din uppmärksamhet gått vidare till nya programutmaningar.

Begränsa synligheten

Att begränsa klassens internals synlighet till omvärlden är en hörnsten i objektorienterad programmering. Klassen ska vara ansvarig för sitt interna tillstånd - om någonting blir inkopplat i klassen, så är det klassprogrammerarens fel. Applikationsprogrammeraren borde oroa sig för att lösa problemet vid handen.

Särskilt innebär begränsad synlighet att datadeledamöter inte ska vara tillgängliga utanför klassen - det vill säga de ska märkas som skyddade. Dessutom måste medlemsfunktioner som applikationsprogrammet inte behöver veta om det också vara märkt skyddat. Utsätt inte mer av klassens internals än vad som behövs för att få jobbet gjort.

Håll koll på heapminne

Förlorade spår av heapminne är den vanligaste källan till dödliga fel i program som har släppts ut i fältet - och samtidigt det svåraste problemet att spåra och ta bort. (Eftersom den här klassen av fel är så svår att hitta och ta bort, är den vanlig i program som du köper.) Du kan behöva köra ett program i timmar innan problem uppstår (beroende på hur stor minnesläckan är).

Som regel bör programmerare alltid allokera och släppa heapminne på samma nivå. "Om en medlem funktion MyClass:: create () allokerar ett block med heapminne och returnerar det till den som ringer, då borde det finnas en medlem MyClass:: release () som returnerar den till högen.Specifikt bör MyClass:: create () inte kräva att moderfunktionen släpper ut minnet.

Om det är möjligt borde MyClass hålla koll på sådana minnespekare på egen hand och radera dem i destructorn.

Nollpunktsindikatorer efter borttagning av vad de pekar på

Se till att du nollar ut pekare efter att de inte längre är giltiga. du gör det genom att tilldela dem värdet nullptr. Anledningen till denna åtgärd blir tydlig med erfarenhet: Du kan fortsätta att använda ett minnesblock som har returnerats till högen och vet inte ens det. Ett program kan fungera bra 99 procent av tiden, vilket gör det mycket svårt att hitta 1 procent av fallen där blocken omfördelas och programmet inte fungerar.

Om du nollställer pekare som inte längre är giltiga och du försöker använda dem för att lagra ett värde (du kan inte lagra någonting vid eller nära nullplatsen), kommer ditt program att krascha omedelbart. Krasning låter dåligt, men det är inte om det utsätter ett problem. Problemet är där; det är bara en fråga om huruvida du hittar det eller inte innan du sätter den i produktion.

Använd undantag för att hantera fel

Undantagsmekanismen i C ++ är utformad för att hantera fel på ett bekvämt och effektivt sätt. I allmänhet bör du kasta en felindikator snarare än att returnera en felflagga. Den resulterande koden är lättare att skriva, läsa och underhålla. Dessutom har andra programmerare kommit att förvänta sig det, och du skulle inte vilja svika dem, skulle du?

Begränsa din användning av undantag till verkliga fel. Det är inte nödvändigt att kasta ett undantag från en funktion som returnerar en "fungerade" indikator om det här är en del av vardagen för den funktionen.

Förklara destructorer virtuella

Glöm inte att skapa en destructor för din klass om konstruktören allokerar resurser som heapminne som måste returneras när objektet når sin ultimata bortgång. Har skapat en destructor, glöm inte att förklara den virtuell.

"Men," säger du, "min klass arv inte från någonting, och den är inte underklassad av en annan klass. "Ja, men det kan bli en basklass i framtiden. Om du inte har någon bra anledning att inte förklara destruktorn virtuell, gör så när du först skapar klassen.

Ge en kopiekonstruktör och överbelastad uppdragsoperatör

Om din klass behöver en destructor behöver den nästan en kopikonstruktör och en överbelastad uppdragsoperatör. Om din konstruktör allokerar resurser som heapminne, gör standardkonstruktören och uppdragsoperatören inget annat än att skapa förödelse genom att generera flera pekare till samma resurser.

När destruktorn för ett av dessa objekt åberopas, kommer det att återställa tillgångarna. När destruktorn för den andra kopian kommer med, kommer den att skruva upp saker.