Programmatore (i) principiante (i) frustrato dalla mancanza di un glossario di errori del compilatore

Un amico della mia famiglia mi ha chiesto un po 'di aiuto mentre impara a programmare (in linguaggio C). Mentre stavamo parlando, ha espresso frustrazione per avere difficoltà a capire i messaggi di errore che il suo compilatore (GCC) gli sta dando quando commette errori. Non capisce tutti i termini usati, e talvolta è la loro combinazione che va oltre la sua comprensione. Mi stava chiedendo "Come mai la documentazione del compilatore non include spiegazioni più lunghe dei messaggi di errore?" - e non avevo una buona risposta per lui.

Io stesso - come programmatore più esperto - mi trovo molto raramente in questa situazione, ma accadono quei rari eventi - un messaggio di errore esotico che non avevo mai incontrato prima. Riesco a cavarmela cercando il messaggio di errore in un motore di ricerca, ma a quanto pare non sempre funziona per lui, soprattutto perché gli errori che incontra sono più comuni e si verificano in più casi distinti, che ha problemi relativi al suo proprio.

Quindi, come dovrebbe un programmatore principiante affrontare la sfida di comprendere i messaggi di errore del compilatore? In particolare, con la combinazione di C e GCC?

Alcune tecniche utili:

• Accendi -Walle -Werror. Potrebbe sembrare controintuitivo quando si fatica a decifrare i messaggi di errore per creare ancora più messaggi di errore, ma gli avvisi sono in genere più facili da capire e più vicini alla fonte effettiva del problema e ignorarli può portare a errori che sono difficili da capire .
• Prova solo a correggere il primo errore nell'elenco. Spesso gli errori si combinano a vicenda, portando a messaggi di errore successivi che non sono realmente errori reali. Risolvi uno e ricompila. Migliorerai nel correggere più messaggi di errore quando acquisirai più esperienza.
• Utilizza la versione del compilatore più recente possibile. C è un linguaggio estremamente stabile. Pertanto, gran parte dei miglioramenti apportati ai compilatori più recenti non consiste nell'aggiungere funzionalità linguistiche, ma nel migliorare l'esperienza degli sviluppatori, compresi i migliori messaggi di errore. Molte distribuzioni Linux ampiamente utilizzate hanno versioni molto vecchie di gcc per impostazione predefinita.
• Programma in modo incrementale. Non provare a scrivere una tonnellata di codice prima di compilare. Scrivi la quantità più breve possibile che verrà comunque compilata. Se hai modificato solo una riga dall'ultima volta che è stata compilata in modo pulito, è molto più facile capire quale riga contiene il problema reale.
• Scrivi unit test. Ti rende più sicuro apportare chiarimenti alle modifiche del refactoring durante la correzione degli errori di compilazione.

Il tuo amico non ha bisogno di un glossario. Un glossario non lo aiuterà. Ciò di cui ha bisogno è una migliore intuizione su cosa fare quando si verificano errori del compilatore.

Gli errori del compilatore C non sono così intuitivi come, diciamo, gli errori del compilatore C #, per molte ragioni principalmente legate alla natura "vicina al metallo" di C. La risoluzione degli errori del compilatore in C non è un esercizio di abbinamento dei modelli, perché l'errore ricevere potrebbe non avere nulla a che fare con il problema reale. A differenza di C # o Java, dove un messaggio di errore in genere si associa a una posizione e un problema di codice precisi, è probabile che gli errori in C siano numerosi e lontani.

Un esempio di questo è "punto e virgola previsto" o qualsiasi numero di errori di sintassi che indicano che il parser è stato bloccato su qualcosa (non necessariamente un punto e virgola). O qualcosa come "dichiarazione anticipata imprevista", un errore che, quando lo vedo, significa inevitabilmente che ho sbagliato le lettere maiuscole in uno dei miei file .h, ma che non indica il file .h come l'origine del problema.

La strategia del tuo amico non dovrebbe essere quella di abbinare questo a un elenco di errori e soluzioni; dovrebbe essere per capire la sintassi e le specifiche del linguaggio C abbastanza bene da capire qual è il problema reale .

Una tecnica pertinente degna di nota è l'utilizzo di un secondo compilatore. Clang ha investito in messaggi di errore migliori, ad esempio, ma qualsiasi modo alternativo per pronunciare l'errore può essere illuminante.

Questo è particolarmente vero per il tipo più complesso di errori. Ad esempio, quando si confondono due costrutti simili (non insoliti per i principianti), i compilatori hanno in genere un problema nella generazione del messaggio di errore corretto. Ciò può causare confusione quando il compilatore fornisce un messaggio di errore sull'utilizzo errato del costrutto A quando si intendeva effettivamente il costrutto B. Un secondo compilatore potrebbe dedurre che si intendesse B.

Qualcuno ha fatto un tentativo nel glossario degli errori GCC su Wikibooks qualche tempo fa, ma sembra che non sia mai decollato e non sia stato aggiornato.

La sezione "Errori" è molto più avanti della sezione "Avvertenze". Sembra che fosse indirizzato a G ++, ma è probabile che ci siano ancora alcune informazioni utili per il tuo amico.

Oltre alle risposte di cui sopra, tieni presente che la maggior parte dei compilatori non dispone di glossari di errori completi: sarebbe molto lavoro da mantenere poiché i messaggi stessi cambiano spesso e ce ne sono molti.

Il miglior sostituto per un glossario è l'accesso a Internet. Ogni volta che il compilatore produce un errore che non capisci, conforta che è altamente improbabile che tu sia il primo ad averlo incontrato ed essere stato confuso. Un rapido Google del messaggio esatto è spesso sufficiente per darti molte informazioni in un formato di facile lettura, spesso con un codice di esempio molto simile al tuo.

Oltre a ciò, tutto il tempo e la familiarità con la lingua e il compilatore sono tutto ciò di cui hai bisogno. Quello e il buon consiglio dato da Karl Bielefeldt .

Lo standard C usa una serie di termini come "lvalue" e "object" in modi diversi dagli altri linguaggi di programmazione e i messaggi del compilatore sono spesso scritti in tali termini. L'uso della terminologia è incoerente in alcune parti dello standard, ma chiunque desideri imparare C dovrebbe esaminare le bozze degli standard C89, C99 e / o C11, nonché i documenti logici per essi. La ricerca, ad esempio, "bozza C99" o "logica C89" dovrebbe funzionare abbastanza bene, anche se potrebbe essere necessario assicurarsi di ottenere il documento che ci si aspetta. Sebbene la maggior parte dei compilatori supporti lo standard C99, può essere utile sapere in che modo differisce dallo standard C89 e la logica C89 può offrire un background storico che le versioni successive non lo fanno.

Sono sorpreso che nessuno abbia dato la risposta ovvia e, sospetto, quello più spesso usato in pratica: semplicemente non leggere i messaggi di errore.

La stragrande maggioranza del valore della maggior parte dei messaggi di errore è semplicemente che qualcosa non va su tale e tale linea. Il più delle volte guardo solo il numero di riga e vado a quella riga. La mia "lettura" del messaggio di errore a quel punto di solito è esattamente ciò che il mio sguardo cattura di sfuggita, nemmeno una scrematura. Se non si capisce subito cosa c'è che non va nella linea o vicino, allora in realtà leggerò il messaggio. Questo flusso di lavoro è ancora migliore con un IDE o uno strumento che evidenzia errori sul posto e realizza automaticamente il suggerimento di Karl Bielefeldt di considerare solo piccoli cambiamenti.

Naturalmente, i messaggi di errore non puntano sempre alla riga appropriata, ma spesso non indicano nemmeno la causa principale appropriata, quindi anche una piena comprensione del messaggio di errore sarebbe di aiuto limitato. Non ci vuole molto per avere un'idea di quali messaggi di errore sono più affidabili nel trovare la linea corretta.

Da un lato, la maggior parte degli errori che un principiante potrebbe commettere sono probabilmente dolorosamente ovvi per un programmatore esperto senza che sia necessario l'aiuto del compilatore. D'altra parte, è molto meno probabile che siano così ovvi per il principiante (anche se molti saranno ovvi, la maggior parte degli errori sono errori stupidi). A questo punto sono completamente d'accordo con Robert Harvey, il novizio ha semplicemente bisogno di familiarizzare con la lingua. Non si può evitare questo. Gli errori del compilatore che fanno riferimento a concetti sconosciuti o sembrano sorprendenti dovrebbero essere visti come suggerimenti per approfondire la conoscenza della lingua. Allo stesso modo per i casi in cui il compilatore si lamenta ma non si vede perché il codice è errato.

Ancora una volta, concordo con Robert Harvey sulla necessità di una strategia migliore per l'utilizzo degli errori del compilatore. Ho delineato alcuni aspetti sopra e la risposta di Robert Harvey fornisce altri aspetti. Non è nemmeno chiaro cosa il tuo amico speri di fare con un "glossario" del genere, ed è molto improbabile che un simile "glossario" possa effettivamente essere di grande utilità per il tuo amico. I messaggi del compilatore non sono certamente il posto per un'introduzione ai concetti del linguaggio ¹ e un "glossario" non è un posto molto migliore per esso. Anche con una descrizione lucida di cosa significa il messaggio di errore, non ti dirà come risolvere il problema.

¹ Alcune lingue, come Elm e Dhall (e probabilmente Racket), così come alcune implementazioni di lingue "orientate ai principianti" tentano di farlo. In questo senso, il consiglio di MSalters di utilizzare un'implementazione diversa è direttamente pertinente. Personalmente trovo queste cose poco interessanti e non del tutto mirate al giusto problema. Questo non vuol dire che non ci sono modi per rendere migliori i messaggi di errore, ma, per me, tendono a girare intorno a rendere più chiare le credenze del compilatore e la base di quelle credenze.

Quindi, come dovrebbe un programmatore principiante affrontare la sfida di comprendere i messaggi di errore del compilatore? In particolare, con la combinazione di C e GCC?

Di 'al tuo amico di fare quanto segue quando incontra un errore che non capisce:

• Rimuovi / commenta il codice aggiunto dall'ultima build riuscita.
• Rimettine piccole parti e compilale
• Ripetere fino a quando si verifica l'errore

Gli errori del compilatore indicano solo ciò che il compilatore non comprende sul codice e non ciò che non va. Questo approccio richiede all'incirca la stessa quantità di tempo in cui si cerca su Google l'errore e la lettura di alcuni documenti o un post StackOverflow, ma fornisce una comprensione molto migliore di ciò che si sta facendo di sbagliato.

Falli anche compilare spesso fino a quando non iniziano a lavorare su progetti che richiedono minuti per essere compilati, individuando gli errori prima di aggiungere troppo altro codice aiuta molto.

Infine, dì loro di lavorare su una cosa alla volta, non lavorare su più file senza compilare in mezzo, non introdurre più dipendenze contemporaneamente, ecc.

Un'altra tecnica sarebbe che l'amico scrivesse il proprio glossario nel tempo quando incontra diversi messaggi di errore. Spesso il modo migliore per imparare qualcosa è insegnarlo. Naturalmente, quando il glossario sarà finito, probabilmente non ne avrà più bisogno.

La mia esperienza personale con GCC è che ogni messaggio di errore si riferisce a una serie "abituale" di errori. Ad esempio, quando GCC dice "hai dimenticato il &", di solito significa che ho dimenticato le parentesi. Naturalmente, quali errori corrispondono a quali messaggi di errore dipenderanno dal programmatore, un'altra buona ragione per cui l'amico deve scrivere il proprio glossario.