Anfängerprogrammierer sind frustriert über das Fehlen eines Glossars mit Compilerfehlern

Ein Freund meiner Familie bat mich um ein wenig Hilfe, während er das Programmieren lernt (in der C-Sprache). Während des Gesprächs äußerte er sich frustriert darüber, dass es ihm schwerfällt, die Fehlermeldungen zu verstehen, die ihm sein Compiler (GCC) gibt, wenn er Fehler macht. Er versteht nicht alle verwendeten Begriffe, und manchmal ist es ihre Kombination, die er nicht versteht. Er fragte mich: "Warum enthält die Compiler-Dokumentation keine längeren Erklärungen der Fehlermeldungen?" - und ich hatte keine gute Antwort für ihn.

Ich selbst - als erfahrener Programmierer - bin sehr selten in dieser Situation, aber diese seltenen Vorkommnisse kommen vor - eine exotische Fehlermeldung, die ich vorher nicht erlebt hatte. Ich komme mit der Suche nach der Fehlermeldung in einer Suchmaschine zurecht, aber anscheinend funktioniert das bei ihm nicht immer - zumal die Fehler, auf die er stößt, häufiger sind und in mehreren Fällen auftreten, die er nur schwer mit seinen in Verbindung bringen kann besitzen.

Wie sollte ein unerfahrener Programmierer die Herausforderung des Verstehens von Compilerfehlermeldungen angehen? Insbesondere mit der Kombination von C und GCC?

Einige nützliche Techniken:

• Einschalten -Wallund -Werror. Es mag uninteressant erscheinen, wenn Sie mit der Entschlüsselung von Fehlermeldungen zu kämpfen haben, um noch mehr Fehlermeldungen zu erstellen. Die Warnungen sind jedoch in der Regel leichter zu verstehen und näher an der eigentlichen Ursache des Problems, und das Ignorieren kann zu schwer verständlichen Fehlern führen .
• Versuchen Sie einfach, den ersten Fehler in der Liste zu beheben. Oft verschmelzen die Fehler miteinander, was dazu führt, dass spätere Fehlermeldungen keine wirklichen Fehler sind. Beheben Sie eine und kompilieren Sie neu. Sie können mehrere Fehlermeldungen besser beheben, wenn Sie mehr Erfahrung sammeln.
• Verwenden Sie die neueste Compiler-Version. C ist eine extrem stabile Sprache. Daher besteht ein großer Teil der Verbesserungen in neueren Compilern nicht darin, Sprachfunktionen hinzuzufügen, sondern die Entwicklererfahrung zu verbessern, einschließlich besserer Fehlermeldungen. Viele weit verbreitete Linux-Distributionen haben standardmäßig sehr alte Versionen von gcc.
• Inkrementell programmieren. Versuchen Sie nicht, eine Tonne Code zu schreiben, bevor Sie kompilieren. Schreiben Sie den kleinstmöglichen Betrag, der noch kompiliert werden kann. Wenn Sie seit der letzten sauberen Kompilierung nur eine Zeile geändert haben, ist es viel einfacher, herauszufinden, in welcher Zeile sich das eigentliche Problem befindet.
• Schreiben Sie Komponententests. Dadurch können Sie sicherer Änderungen am Refactoring vornehmen, wenn Sie Kompilierungsfehler beheben.

Ihr Freund braucht kein Glossar. Ein Glossar hilft ihm nicht. Was er braucht, ist eine bessere Intuition darüber, was zu tun ist, wenn Compilerfehler auftreten.

C-Compiler-Fehler sind nicht so intuitiv wie beispielsweise C # -Compiler-Fehler, und zwar aus vielen Gründen, die in erster Linie mit der "Nähe zum Metall" von C zu tun haben empfangen kann nichts mit dem eigentlichen Problem zu tun haben. Im Gegensatz zu C # oder Java, bei denen eine Fehlermeldung in der Regel eine genaue Codestelle und ein genaues Problem aufweist, sind Fehler in C wahrscheinlich zahlreich und weit verbreitet.

Ein Beispiel hierfür ist "Semikolon erwartet" oder eine beliebige Anzahl von Syntaxfehlern, die darauf hinweisen, dass der Parser an etwas hängengeblieben ist (nicht unbedingt ein Semikolon). Oder so etwas wie "Unerwartete Vorwärtsdeklaration", ein Fehler, der, wenn ich ihn sehe, ausnahmslos bedeutet, dass ich in einer meiner .h-Dateien eine falsche Großschreibung vorgenommen habe, aber nicht auf die .h-Datei als Ursache des Problems hinweist.

Die Strategie Ihres Freundes sollte nicht darin bestehen, das Muster mit einer Liste von Fehlern und Lösungen abzugleichen. es sollte sein, die Syntax und Spezifikation der C-Sprache gut genug zu verstehen, um herauszufinden, was das eigentliche Problem ist.

Eine relevante erwähnenswerte Technik ist die Verwendung eines zweiten Compilers. Clang hat zum Beispiel in bessere Fehlermeldungen investiert, aber jede andere Möglichkeit, den Fehler auszudrücken, kann aufschlussreich sein.

Dies gilt insbesondere für die komplexesten Arten von Fehlern. Wenn Sie beispielsweise zwei ähnliche Konstrukte mischen (was für Anfänger nicht ungewöhnlich ist), haben Compiler in der Regel Probleme, die richtige Fehlermeldung zu generieren. Dies kann zu Verwirrung führen, wenn der Compiler eine Fehlermeldung über die falsche Verwendung von Konstrukt A ausgibt, wenn Sie tatsächlich Konstrukt B beabsichtigt haben. Ein zweiter Compiler könnte darauf schließen, dass Sie B beabsichtigt haben.

Jemand hat vor einiger Zeit einen Versuch unternommen, ein GCC-Fehlerglossar für Wikibooks zu erstellen , aber es sieht so aus, als wäre es nie ganz aufgegangen und wurde nicht aktualisiert.

Der Abschnitt "Fehler" ist viel weiter entfernt als der Abschnitt "Warnungen". Es sieht so aus, als wäre es an G ++ gerichtet, aber es gibt wahrscheinlich immer noch einige nützliche Informationen für Ihren Freund.

Beachten Sie zusätzlich zu den obigen Antworten, dass die meisten Compiler keine umfassenden Fehlerglossare haben - dies wäre eine Menge Arbeit, da sich die Nachrichten selbst häufig ändern und es ziemlich viele von ihnen gibt.

Der beste Ersatz für ein Glossar ist der Zugang zum Internet. Wenn der Compiler einen Fehler ausgibt, den Sie nicht verstehen, gehen Sie davon aus, dass es sehr unwahrscheinlich ist, dass Sie der Erste sind, der auf ihn gestoßen ist und verwirrt wurde. Ein schnelles Auffinden der genauen Nachricht durch Google ist häufig ausreichend, um Ihnen viele Informationen in einem einfach zu lesenden Format zur Verfügung zu stellen, häufig mit einem Beispielcode, der Ihrem eigenen Code sehr ähnlich ist.

Darüber hinaus ist Zeit und Vertrautheit mit der Sprache und dem Compiler alles, was Sie brauchen. Das und der gute Rat von Karl Bielefeldt .

Der C-Standard verwendet eine Reihe von Begriffen wie "lvalue" und "object" auf eine Weise, die sich von anderen Programmiersprachen unterscheidet, und Compilermeldungen werden häufig in diesen Begriffen geschrieben. Die Verwendung von Terminologie ist in einigen Teilen des Standards inkonsistent. Wer jedoch C erlernen möchte, sollte sich die Entwürfe der Standards C89, C99 und / oder C11 sowie die zugehörigen Begründungsdokumente ansehen. Die Suche nach beispielsweise "C99 Entwurf" oder "C89 Begründung" sollte ziemlich gut funktionieren, obwohl Sie möglicherweise sicherstellen müssen, dass Sie das erwartete Dokument erhalten. Obwohl die meisten Compiler den C99-Standard unterstützen, kann es nützlich sein, zu wissen, wie er sich vom C89-Standard unterscheidet, und die C89-Begründung bietet möglicherweise einen historischen Hintergrund, den spätere Versionen nicht bieten.

Ich bin überrascht, dass niemand die offensichtliche Antwort gegeben hat und ich vermute, die in der Praxis am häufigsten verwendete: Lies einfach nicht die Fehlermeldungen.

Die überwiegende Mehrheit des Werts der meisten Fehlermeldungen besteht einfach darin, dass in dieser oder jener Zeile etwas nicht stimmt. Meistens schaue ich mir nur die Zeilennummer an und gehe zu dieser Zeile. Mein "Lesen" der Fehlermeldung zu diesem Zeitpunkt ist normalerweise genau das, was mein Auge im Vorbeigehen bemerkt, nicht einmal ein Überfliegen. Wenn nicht sofort klar ist, was an oder in der Nähe der Leitung nicht stimmt, lese ich die Nachricht tatsächlich. Dieser Workflow ist mit einer IDE oder einem Tool, das Fehler vor Ort hervorhebt, noch besser und befolgt automatisch den Vorschlag von Karl Bielefeldt, nur kleine Änderungen zu berücksichtigen.

Natürlich zeigen die Fehlermeldungen nicht immer auf die entsprechende Zeile, aber dann zeigen sie oft auch nicht auf die entsprechende Grundursache, sodass selbst ein umfassendes Verständnis der Fehlermeldung nur bedingt hilfreich ist. Es dauert nicht lange, um eine Vorstellung davon zu bekommen, welche Fehlermeldungen zuverlässiger sind, wenn es darum geht, die richtige Leitung zu finden.

Einerseits sind die meisten Fehler, die ein Anfänger wahrscheinlich macht , für einen erfahrenen Programmierer schmerzhaft offensichtlich, ohne dass die Hilfe des Compilers erforderlich ist. Auf der anderen Seite ist es weniger wahrscheinlich, dass sie für den Anfänger so offensichtlich sind (obwohl viele offensichtlich sind, sind die meisten Fehler dumme Fehler). An diesem Punkt stimme ich Robert Harvey voll und ganz zu, der Anfänger muss sich nur mit der Sprache vertraut machen. Daran führt kein Weg vorbei. Compiler-Fehler, die auf unbekannte Konzepte verweisen oder überraschend erscheinen, sollten als Aufforderung zur Vertiefung der Sprachkenntnisse angesehen werden. Ähnliches gilt für Fälle, in denen der Compiler sich beschwert, Sie jedoch nicht erkennen können, warum der Code falsch ist.

Auch hier stimme ich Robert Harvey zu, dass eine bessere Strategie zur Ausnutzung von Compilerfehlern erforderlich ist. Ich habe oben einige Aspekte umrissen, und die Antwort von Robert Harvey enthält andere Aspekte. Es ist nicht einmal klar, was Ihr Freund mit einem solchen "Glossar" zu tun hofft, und es ist sehr unwahrscheinlich, dass ein solches "Glossar" Ihrem Freund tatsächlich von großem Nutzen ist. Compilerbotschaften sind sicherlich nicht der Ort für eine Einführung in die Konzepte der Sprache ¹ und ein "Glossar" ist dafür nicht viel besser geeignet. Selbst mit einer klaren Beschreibung der Bedeutung der Fehlermeldung erfahren Sie nicht, wie Sie das Problem beheben können .

¹ Einige Sprachen wie Elm und Dhall (und wahrscheinlich Racket) sowie einige "Anfänger-orientierte" Implementierungen von Sprachen versuchen dies jedoch. In diesem Sinne ist der Rat von MSalters, eine andere Implementierung zu verwenden, direkt relevant. Ich persönlich finde solche Dinge nicht überzeugend und nicht ganz auf das richtige Problem ausgerichtet. Das soll nicht heißen, dass es keine Möglichkeiten gibt, bessere Fehlermeldungen zu erstellen, aber für mich dreht sich alles darum, die Überzeugungen des Compilers und die Grundlage dieser Überzeugungen klarer zu machen.

Wie sollte ein unerfahrener Programmierer die Herausforderung des Verstehens von Compilerfehlermeldungen angehen? Insbesondere mit der Kombination von C und GCC?

Bitten Sie Ihren Freund, Folgendes zu tun, wenn er auf einen Fehler stößt, den er nicht versteht:

• Entfernen / kommentieren Sie den Code, der seit dem letzten erfolgreichen Build hinzugefügt wurde.
• Setzen Sie kleine Teile davon zurück und kompilieren Sie
• Wiederholen, bis der Fehler auftritt

Compiler-Fehler sagen Ihnen nur, was der Compiler über Ihren Code nicht versteht, und nicht, was daran falsch ist. Dieser Ansatz benötigt ungefähr die gleiche Zeit wie das Durchsuchen des Fehlers und das Lesen einiger Dokumente oder eines StackOverflow-Posts, bietet jedoch ein besseres Verständnis dafür, was Sie falsch machen.

Lassen Sie sie auch so oft kompilieren, bis sie anfangen, an Projekten zu arbeiten, deren Erstellung einige Minuten in Anspruch nimmt. Dabei hilft es, Fehler zu entdecken, bevor zu viel anderer Code hinzugefügt wird.

Schließlich fordern Sie sie auf, jeweils an einer Sache zu arbeiten, nicht in mehreren Dateien zu arbeiten, ohne dazwischen zu kompilieren, keine mehreren Abhängigkeiten gleichzeitig einzuführen usw.

Eine andere Technik wäre, dass der Freund im Laufe der Zeit sein eigenes Glossar schreibt, wenn er auf verschiedene Fehlermeldungen stößt. Oft ist der beste Weg, etwas zu lernen, es zu lehren. Natürlich wird er es wahrscheinlich nicht mehr brauchen, wenn das Glossar fertig ist.

Meine persönliche Erfahrung mit GCC ist, dass sich jede Fehlermeldung auf eine "übliche" Reihe von Fehlern bezieht. Wenn GCC beispielsweise sagt, dass Sie das & vergessen haben, bedeutet dies normalerweise, dass ich Klammern vergessen habe. Welche Fehler mit welchen Fehlermeldungen verbunden sind, hängt natürlich vom Programmierer ab, ein weiterer guter Grund für den Freund, sein eigenes Glossar zu schreiben.