Undviker fel i ditt C ++-program - dummies

Börja inte felsöka din kod tills du tar bort eller åtminstone förstår alla varningar som genereras under sammanställningen. Aktiverar alla varningsmeddelanden om du då ignorerar dem, gör du inte bra. Om du inte förstår varningen, kolla upp den. Vad du inte känner kommer skada dig.

Antag en tydlig och konsekvent kodningsstil

Kodning i en tydlig och konsekvent stil förstärker inte bara läsbarheten av programmet utan resulterar också i färre kodningsfel. Kom ihåg, ju mindre hjärnkraft du måste spendera dechiffrera C ++-syntaxen, desto mer har du lämnat för att tänka på logiken i programmet till hands. En bra kodningsstil gör att du enkelt kan göra följande:

• Differentiera klassnamn, objektnamn och funktionsnamn
• Veta något om objektet baserat på dess namn
• Differentiera preprocessorsymboler från C ++-symboler (det vill säga #definierade objekt ska sticka ut)
• Identifiera block av C ++-kod på samma nivå (detta är resultatet av konsekvent indragning)

Dessutom måste du upprätta en standardmodulhuvud som ger information om funktionerna eller klasserna i modulen, författaren (förmodligen det är du), datumet, versionen av kompilatorn du använder och en ändringshistorik.

Slutligen bör alla programmerare som är inblandade i ett enda projekt använda samma stil. Att försöka dechiffrera ett program med ett lapptäcke av olika kodningsstilar är förvirrande.

Kommentera din kod när 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. Det tar inte tid att skriva volymerande rubriker och funktionsbeskrivningar fram till senare, men du har alltid tid att lägga till korta kommentarer när du skriver koden.

Korta kommentarer ska vara upplysande. Om de inte är det, är de inte värda mycket och du borde göra något annat istället. Du behöver all den upplysning du kan få när du försöker göra ditt program arbete. När du tittar på ett kodstycke som du skrev för några dagar sedan kan kommentarer som är korta, beskrivande och till den punkten göra ett dramatiskt bidrag till att hjälpa dig att räkna ut exakt vad det var du försökte göra.

Dessutom gör kodningen enklare att förstå med konsekvent kodinriktning och namngivningskonventioner. Det är väldigt trevligt när koden är lätt att läsa när du är klar med den, men det är lika viktigt att koden är lätt att läsa medan du skriver den. Det är då du behöver hjälp.

Enkelt steg varje väg minst en gång

Som programmerare är det viktigt för dig att förstå vad ditt program gör. Ingenting ger dig en bättre känsla för vad som händer under huven än att förstärka programmet med en bra debugger. (Debuggarna som ingår i IDE för interaktiva kompilatorer fungerar bara bra.)

Utöver det, när du skriver ett program behöver du ibland råmaterial för att räkna ut lite bisarrt beteende. Ingenting ger dig det materialet bättre än enstegs nya funktioner när de träder 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 funktionen granskas av sig själv snarare än efter att den har kastats i grytan med resten av funktionerna - och din uppmärksamhet har gått på nya programutmaningar.

Undvik överbelastning av operatörer

Annat än att använda operatören operatören för operatören () och operatören >> () och operatören för uppdragsoperatören = (), bör du förmodligen hålla bort överbelastningsoperatörer tills du känner dig bekväm med C ++. Även om en bra uppsättning överbelastade operatörer kan öka användbarheten och läsbarheten hos en ny klass, är överbelastningsoperatörer (andra än de tre som just listats) nästan aldrig nödvändiga och kan väsentligt lägga till din debugging woes som ny programmerare. Du kan få samma effekt genom att definiera och använda de riktiga offentliga medlemsfunktionerna istället.

När du har varit C-Plus-Plussing i några månader, var god att återvända och börja överbelasta operatörerna till ditt hjärtans innehåll.

Balanshanteringshantering Programmerare bör allmänt allokera och släppa upp minnesminne på samma nivå. "Om en medlemsfunktion MyClass:: create () allokerar ett block med heapminne och returnerar det till den som ringer, då ska det finnas en medlemsfunktion MyClass:: release () som returnerar minnet till högen. Specifikt bör MyClass:: create () inte kräva att moderfunktionen släpper ut sig själv. Detta undviker absolut inte alla minnesproblem - föräldrafunktionen kan glömma att ringa MyClass:: release ()

- men det minskar möjligheten något.

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. Nu när den här funktionen har standardiserats ska du använda den. Den resulterande koden är lättare att skriva, lättare att läsa och lättare att underhålla. Dessutom har andra programmerare kommit att förvänta sig det - du vill inte svika dem, skulle du?

Undvik flera arv

Flera arv, som överbelastning av operatörer, lägger till en annan nivå av komplexitet som du inte behöver hantera när du just börjat. Lyckligtvis kan de flesta verkliga relationer beskrivas med ett enda arv.

Känn dig fri att använda flera arvade klasser från kommersiella bibliotek, till exempel Microsoft MFC-klasserna.Microsoft har spenderat mycket tid på att skapa sina klasser och vet vad den gör.

När du känner dig bekväm med din nivå av förståelse för C ++, försök med att konfigurera några arvshierarkier för flera arv. På det sättet är du redo om du behöver det.