10 Moduri de a evita bug-uri în C ++ - dummies

Este un lucru nefericit că veți petrece mai mult timp pentru a căuta și a elimina bug-uri decât veți petrece de fapt scrierea programelor dvs. C ++ în primul rând. Sugestiile de aici vă pot ajuta să minimalizați numărul de erori pe care le introduceți în programele dvs. pentru a face programarea o experiență mai plăcută.

Activați toate avertismentele și mesajele de eroare

Sintaxa C ++ permite o mulțime de verificări de eroare. Când compilatorul întâlnește o construcție pe care doar nu o poate descifra, nu are altă soluție decât să dea un mesaj. Se încearcă sincronizarea copiilor de rezervă cu codul sursă (uneori mai puțin decât cu succes), dar nu va genera un executabil. Acest lucru obligă programatorul să remedieze toate mesajele de eroare.

Dezactivarea sau ignorarea în alt mod a avertismentelor este o idee extraordinar de proastă. Este un pic cam ca să deconectați lampa "check engine" de pe tabloul de bord al mașinii pentru că vă deranjează. Ignorarea problemei nu o face să dispară.

Adoptarea unui stil de codare clar și consistent

Scrierea codului dvs. C ++ într-un stil clar și consecvent nu numai că îmbunătățește lizibilitatea programului dvs., ci conduce și la mai puține greșeli de codificare. Această situație oarecum surprinzătoare rezultă din faptul că creierul nostru are doar o cantitate limitată de putere de calcul.

Când citiți un cod care este curat și curat și care urmează unui stil cu care vă cunoașteți, veți petrece foarte puține puteri ale creierului parsând sintaxa instrucțiunilor C ++. Acest lucru lasă mai multă putere creierului CPU să decodeze ceea ce încearcă să facă programul și nu modul în care o face.

Un stil de codare bun vă permite să faceți următoarele cu ușurință:

Diferențiați între nume de clase, nume de obiecte și nume de funcții

• Înțelegeți ce este folosit pentru clasă, funcție sau obiect, pe baza numelui său

• Simboluri preprocesoare diferențiate din simbolurile C ++ (adică #define objects should stand out)

• Identificați blocurile de cod C ++ la același nivel (acesta este rezultatul unei indentări consecvente)

• In în plus, trebuie să stabiliți un format standard pentru anteturile dvs. de module care să furnizeze informații despre funcțiile sau clasele din fiecare modul, autorul, data, versiunea și ceva despre istoricul modificărilor.

Toți programatorii implicați într-un singur proiect ar trebui să utilizeze același stil de codificare. Un program scris într-un mozaic de diferite stiluri de codificare este confuz și pare neprofesional.

Comentează codul în timp ce-l scrii

Poți evita erorile dacă îți comentezi codul în timp ce-l scrii, mai degrabă decât să aștepți până când totul funcționează și apoi să te întorci și să adaugi comentarii.

Formularea comentariilor vă forțează să faceți o analiză a ceea ce încercați să faceți. Comentariile scurte sunt luminante, atât când le citești mai târziu, cât și pe măsură ce le scrii. Scrieți comentarii ca și cum ați vorbi cu un alt programator informat.

Fiecare cale în cel puțin o dată

în programul de depanare Ca programator, trebuie să înțelegi ce face programul tău. Nu este suficient ca programul să furnizeze valoarea așteptată. Trebuie să înțelegi tot ce faci programul tău. Nimic nu vă dă o senzație mai bună despre ceea ce se petrece sub capotă decât programul

cu un singur pas , executându-l pas cu pas cu un program de depanare bun (cum ar fi cel care vine cu Cod:: Blocuri). Dincolo de faptul că, pe măsură ce depanezi un program, ai nevoie de materii prime pentru a descoperi un comportament bizar care ar putea apărea în timp ce programul rulează. Nimic nu vă oferă acest material mai bine decât o singură trecere prin fiecare funcție în momentul în care vine în folosință.

În cele din urmă, atunci când o funcție este terminată și este gata să fie adăugată la program, fiecare cale logică trebuie călătorită cel puțin o dată. Bug-urile sunt mult mai ușor de găsit atunci când examinați funcția de la sine, mai degrabă decât după ce a fost aruncată în pot cu restul funcțiilor - până atunci, atenția dvs. a continuat cu noi provocări de programare.

Limitați vizibilitatea

Limitarea vizibilității internelor de clasă la lumea exterioară este o piatră de temelie a programării orientate pe obiecte. Clasa ar trebui să fie responsabilă de starea sa internă - dacă se întâmplă ceva în clasă, atunci e vina programatorului de clasă. Programatorul de aplicații ar trebui să vă îngrijoreze cu privire la rezolvarea problemei la îndemână.

În mod specific, vizibilitatea limitată înseamnă că membrii de date nu ar trebui să fie accesibili în afara clasei - adică ar trebui să fie marcați ca fiind protejați. În plus, funcțiile membrilor pe care software-ul aplicației nu trebuie să le cunoască ar trebui, de asemenea, să fie marcate protejate. Nu expuneți nici mai mult din interiorul clasei decât este necesar pentru a vă face treaba.

Urmăriți memoria de heap

Pierderea urmăririi memoriei heap este cea mai frecventă sursă de erori fatale în programele care au fost lansate pe teren - și, în același timp, cea mai dificilă problemă de urmărire și eliminare. (Deoarece această clasă de erori este atât de greu de găsit și de eliminat, este predominantă în programele pe care le cumpărați.) Este posibil să fie nevoie să rulați un program cu ore înainte de apariția problemelor (în funcție de cât de mare este scurgerea memoriei).

Ca regulă generală, programatorii ar trebui să aloce întotdeauna și să elibereze memoria heap la același "nivel". "Dacă un membru al funcției MyClass:: create () alocă un bloc de memorie heap și îl returnează apelantului, atunci ar trebui să existe un membru MyClass:: release () care îl returnează pe heap.Mai exact, MyClass:: create () nu ar trebui să necesite funcția părinte pentru a elibera memoria.

Dacă este posibil, MyClass ar trebui să țină evidența acestor indicii de memorie pe cont propriu și să le șterge în destructor.

Indicați zero după ce ștergeți ceea ce indică

Asigurați-vă că indicați zero după ce acestea nu mai sunt valabile; faceți acest lucru atribuindu-le valoarea nullptr. Motivele acestei acțiuni devin clare cu experiența: puteți continua să utilizați un bloc de memorie care a fost returnat la heap și nici măcar nu-l cunoașteți. Un program ar putea rula în proporție de 99% din timp, ceea ce face foarte dificilă găsirea unui procent din cazurile în care blocul este realocat și programul nu funcționează.

Dacă eliminați indicii care nu mai sunt valabili și încercați să le utilizați pentru a stoca o valoare (nu puteți stoca nimic la sau în apropierea locației nula), programul dvs. va ceda imediat. Crashing sună rău, dar nu este dacă expune o problemă. Problema este acolo; este doar o întrebare dacă îl găsiți sau nu înainte de al pune în producție.

Utilizați excepții pentru a gestiona erorile

Mecanismul de excepție în C ++ este conceput pentru a gestiona erorile convenabil și eficient. În general, ar trebui să aruncați un indicator de eroare în loc să returnați un semn de eroare. Codul rezultat este mai ușor de scris, citit și întreținut. În plus, alți programatori au ajuns să se aștepte la asta și nu ai vrea să-i dezamăgesc, nu-i așa?

Limitați utilizarea excepțiilor la erori reale. Nu este necesar să aruncați o excepție de la o funcție care returnează un indicator "nu funcționează" dacă aceasta este o parte din viața de zi cu zi pentru funcția respectivă.

Declarați destructorii virtuali

Nu uitați să creați un distrugător pentru clasa dvs. dacă constructorul alocă resurse cum ar fi memoria heap care trebuie returnate atunci când obiectul ajunge la decesul final. După ce ați creat un distrugător, nu uitați să îl declarați virtual.

"Dar" spui ", clasa mea nu moșteneste de la nimic și nu este subclasată de altă clasă. "Da, dar

ar putea deveni o clasă de bază în viitor. Dacă nu aveți un motiv bun pentru a nu declara virtual destructorul, atunci faceți acest lucru atunci când creați pentru prima dată clasa. Furnizați un constructor de copiere și un operator de asignare supraîncărcat

Dacă clasa dvs. are nevoie de un destructor, este aproape sigur că are nevoie de un constructor de copie și de un operator de sarcină supraîncărcat. Dacă constructorul dvs. alocă resurse cum ar fi memoria heap, constructorul implicit de copiere și operatorul de atribuire nu vor face decât să creeze dezastru prin generarea de indicatori multiple la aceleași resurse.

Atunci când distrugătorul pentru unul dintre aceste obiecte este invocat, acesta va restaura activele. Când vine distrugătorul pentru celălalt exemplar, acesta va înșuruba lucrurile.