Evitando bug nel tuo programma C ++ - dummies

Non avviare il debug del codice finché non rimuovi o almeno comprendi tutti gli avvisi generati durante la compilazione. Abilitare tutti i messaggi di avviso se poi li ignori non ti va bene. Se non capisci l'avviso, cercalo. Quello che non sai ti farà male .

Adotta uno stile di codifica chiaro e coerente

La codifica in uno stile chiaro e coerente non solo migliora la leggibilità del programma ma comporta anche meno errori di codifica. Ricorda, minore è il potere del cervello che devi dedicare alla decifrazione della sintassi C ++, più ti rimane per pensare alla logica del programma in questione. Un buon stile di codifica ti consente di fare quanto segue con facilità:

• Differenzia nomi di classi, nomi di oggetti e nomi di funzioni
• Conoscere qualcosa sull'oggetto in base al suo nome
• Differenziare i simboli del preprocessore dai simboli C ++ (cioè, # gli oggetti definiti dovrebbero risaltare)
• Identificare blocchi di codice C ++ allo stesso livello (questo è il risultato di un rientro coerente)

Inoltre, è necessario stabilire un'intestazione modulo standard che fornisce informazioni sulle funzioni o classi nel modulo, l'autore (presumibilmente, sei tu), la data, la versione del compilatore che stai utilizzando e una cronologia delle modifiche.

Infine, tutti i programmatori coinvolti in un singolo progetto dovrebbero usare lo stesso stile. Cercare di decifrare un programma con un patchwork di stili di codifica diversi è fonte di confusione.

Commenta il tuo codice mentre lo scrivi

Puoi evitare errori se commenta il tuo codice mentre lo scrivi, piuttosto che attendere fino a quando tutto funziona e quindi tornare indietro e aggiungere commenti. Non prendere il tempo per scrivere intestazioni voluminose e descrizioni delle funzioni fino a tardi è comprensibile, ma hai sempre tempo per aggiungere brevi commenti mentre scrivi il codice.

I commenti brevi dovrebbero essere illuminanti. Se non lo sono, non valgono molto e dovresti invece fare qualcos'altro. Hai bisogno di tutta l'illuminazione che puoi ottenere mentre stai cercando di far funzionare il tuo programma. Quando guardi un pezzo di codice che hai scritto pochi giorni fa, i commenti brevi, descrittivi e al punto possono dare un contributo drammatico per aiutarti a capire esattamente che cosa stavi cercando di fare.

Inoltre, l'indentazione coerente del codice e le convenzioni di denominazione facilitano la comprensione del codice. È tutto molto bello quando il codice è facile da leggere dopo aver finito con esso, ma è altrettanto importante che il codice sia facile da leggere mentre lo stai scrivendo. Questo è quando hai bisogno dell'aiuto.

Singolo passo ogni percorso almeno una volta

Come programmatore, è importante per te capire cosa sta facendo il tuo programma. Niente ti dà una sensazione migliore per quello che sta succedendo sotto il cappuccio di single-stepping del programma con un buon debugger. (I debugger inclusi nell'IDE dei compilatori interattivi funzionano bene).

Oltre a ciò, mentre scrivi un programma, a volte hai bisogno di materiale grezzo per capire un comportamento bizzarro. Nulla ti dà quel materiale meglio delle nuove funzioni a passo singolo man mano che entrano in servizio.

Infine, quando una funzione è finita e pronta per essere aggiunta al programma, ogni percorso logico deve essere percorso almeno una volta. I bug sono molto più facili da trovare quando la funzione viene esaminata da sola piuttosto che dopo che è stata gettata nel piatto con il resto delle funzioni - e la tua attenzione è andata a nuove sfide di programmazione.

Evita di sovraccaricare gli operatori

Oltre a utilizzare i due operatori di I / O del flusso operatore << () e operatore >> () e l'operatore di assegnazione operatore = () , dovresti probabilmente evitare di sovraccaricare gli operatori finché non ti senti a tuo agio con C ++. Sebbene un buon set di operatori sovraccarichi possa aumentare l'utilità e la leggibilità di una nuova classe, gli operatori di overloading (diversi dai tre appena elencati) non sono quasi mai necessari e possono aumentare in modo significativo i problemi di debug come nuovo programmatore. È possibile ottenere lo stesso effetto definendo e utilizzando invece le funzioni membro pubbliche appropriate.

Dopo aver passato C-Plus-Plussing per alcuni mesi, sentiti libero di tornare e iniziare a sovraccaricare gli operatori a tuo piacimento.

Gestione dell'heap della bilancia

Generalmente, i programmatori dovrebbero allocare e rilasciare la memoria heap allo stesso "livello". "Se una funzione membro MyClass:: create () alloca un blocco di memoria heap e lo restituisce al chiamante, quindi dovrebbe esserci una funzione membro MyClass:: release () che restituisce la memoria all'heap. In particolare, MyClass:: create () non dovrebbe richiedere che la funzione genitore rilasci la memoria stessa. Questo certamente non evita tutti i problemi di memoria - la funzione genitore potrebbe dimenticare di chiamare MyClass:: release () - ma in qualche modo riduce la possibilità.

Usa le eccezioni per gestire gli errori

Il meccanismo di eccezione in C ++ è progettato per gestire gli errori in modo comodo ed efficiente. Ora che questa funzione è stata standardizzata, dovresti usarla. Il codice risultante è più facile da scrivere, più facile da leggere e più facile da gestire. Inoltre, altri programmatori se lo aspettano - non vorresti deluderli, vero?

Evita l'ereditarietà

L'ereditarietà multipla, come l'overloading dell'operatore, aggiunge un altro livello di complessità che non è necessario affrontare quando si è appena agli inizi. Fortunatamente, la maggior parte delle relazioni del mondo reale può essere descritta con una singola ereditarietà.

Sentiti libero di utilizzare classi ereditate da più librerie commerciali, come le classi Microsoft MFC.Microsoft ha dedicato molto tempo a impostare le sue classi e sa cosa sta facendo.

Dopo esserti sentito a tuo agio con il tuo livello di comprensione del C ++, prova a configurare alcune gerarchie di ereditarietà multiple. In questo modo, sarai pronto se ne hai bisogno.