コンパイラエラーの用語集がないために不満な初心者プログラマ

私の家族の友人が、プログラミング（C言語）を学ぶときに少し助けを求めました。私たちが話していたとき、彼はコンパイラー（GCC）がエラーを起こしたときに彼に与えるエラーメッセージを理解するのに苦労していることにフラストレーションを表明しました。彼は、使用されているすべての用語を理解していません。また、それらの組み合わせが理解できない場合もあります。「コンパイラのドキュメントに、エラーメッセージの詳細な説明が含まれていないのはなぜですか？」-そして、私は彼に良い答えがありませんでした。

私自身-より経験豊富なプログラマーとして-この状況ではめったにありませんが、これらのまれな出来事は起こります-私が以前に遭遇したことのないいくつかのエキゾチックなエラーメッセージ。私は検索エンジンでエラーメッセージを探すことで何とかやっていくことができますが、どうやらそれは彼のために常に機能するとは限りません-特に彼が遭遇するエラーはより一般的であり、彼が彼に関連するトラブルを抱えている複数の異なるケースで発生するため自分の。

それでは、初心者プログラマはコンパイラエラーメッセージを理解するという課題にどのように取り組むべきでしょうか？具体的には、CとGCCの組み合わせで？

いくつかの便利なテクニック：

• とをオンに-Wallし-Werrorます。エラーメッセージを解読してさらに多くのエラーメッセージを作成しようとすると直観に反するように思えるかもしれませんが、通常、警告は理解しやすく、問題の実際の原因により近いため、無視するとエラーを理解しにくくなる可能性があります。
• リストの最初のエラーを修正してください。多くの場合、エラーは互いに重なり合い、実際のエラーではない後のエラーメッセージにつながります。修正して再コンパイルしてください。経験を積むと、複数のエラーメッセージの修正が上手くなります。
• 可能な限り最新のコンパイラバージョンを使用してください。Cは非常に安定した言語です。したがって、新しいコンパイラの改善の大部分は、言語機能を追加することではなく、より良いエラーメッセージを含む開発者のエクスペリエンスを改善することです。広く使用されている多くのLinuxディストリビューションには、デフォルトでgccの非常に古いバージョンがあります。
• 増分プログラム。コンパイルする前に大量のコードを書こうとしないでください。コンパイルする可能性のある最短の量を書きます。前回正常にコンパイルしてから1行しか変更していない場合、どの行に実際の問題が含まれているかを把握する方がはるかに簡単です。
• 単体テストを作成します。コンパイルエラーを修正する際に、リファクタリングの変更を明確にする自信がつきます。

あなたの友人は用語集を必要としません。 用語集は彼を助けません。彼が必要とするのは、コンパイラエラーが発生したときに何をすべきかについての直感です。

Cコンパイラエラーは、たとえばC＃コンパイラエラーほど直感的ではありません。多くの理由は、主にCの「金属に近い」性質に関係しているためです。Cでのコンパイラエラーの解決は、パターンマッチングの練習ではありません。 receiveは、実際の問題とは何の関係もありません。通常、エラーメッセージが正確なコードの場所と問題にマップされるC＃やJavaとは異なり、Cのエラーは多数あり、遠く離れている可能性があります。

この例としては、「セミコロンが必要」または構文解析器が何か（必ずしもセミコロンではない）にハングアップしたことを示す任意の数の構文エラーがあります。または、「予期しない前方宣言」などのエラーは、見たときに、.hファイルの1つで大文字が間違っていることを常に意味しますが、問題の原因として.hファイルを指していません。

友人の戦略は、これをエラーと解決策のリストにパターン一致させることではありません。C言語の構文と仕様を十分に理解して、実際の問題を把握する必要があります。

言及する価値のある関連技術は、2番目のコンパイラを使用することです。たとえば、Clangはより優れたエラーメッセージに投資していますが、エラーを表現する別の方法は啓発的です。

これは、最も複雑なタイプのエラーの場合に特にそうです。たとえば、2つの類似した構造（初心者にとっては珍しいことではありません）を混在させると、通常、コンパイラは正しいエラーメッセージを生成する際に問題を抱えます。これは、実際にコンストラクトBを意図したときに、コンパイラーがコンストラクトAの誤った使用法に関するエラーメッセージを出すと混乱を引き起こす可能性があります。

誰かがウィキブックスのGCCエラー用語集を少し前に試みましたが、それはまったく成功せず、更新されていないようです。

「エラー」セクションは、「警告」セクションよりもはるかに詳細です。G ++を対象としたように見えますが、そこにはあなたの友人に役立つ情報がまだ残っている可能性があります。

上記の回答に加えて、ほとんどのコンパイラには包括的なエラー用語集がないことに注意してください。これらはメッセージ自体が頻繁に変更されるため、維持するのに多大な労力が必要であり、非常に多くあります。

用語集の最良の代替は、インターネットへのアクセスです。コンパイラーが理解できないエラーを生成するときはいつでも、最初に遭遇して混乱した可能性が非常に低いと安心してください。正確なメッセージをすばやくGoogleに入力するだけで、多くの情報を読みやすい形式で提供することができます。多くの場合、サンプルコードと非常によく似ています。

それ以外に、言語とコンパイラーについての時間と知識があれば十分です。それと、Karl Bielefeldtからの良いアドバイス。

C標準では、他のプログラミング言語とは異なる方法で「左辺値」や「オブジェクト」などの多くの用語を使用しており、コンパイラメッセージはそのような用語で記述されることがよくあります。用語の使用は規格の一部で一貫性がありませんが、Cを学習したい人はC89、C99、および/またはC11規格のドラフトとそれらの根拠文書を参照する必要があります。「C99ドラフト」や「C89の理論的根拠」などを検索することは非常にうまくいくはずですが、期待するドキュメントを取得する必要があるかもしれません。ほとんどのコンパイラはC99標準をサポートしていますが、C89標準との違いを知っておくと役立つ場合があります。

誰も明白な答えを出さなかったことに驚いています。実際に最も頻繁に使用されるのは、エラーメッセージを読まないでください。

ほとんどのエラーメッセージの価値の大部分は、単にそのような行で何かが間違っているということです。ほとんどの場合、私は単に行番号を見て、その行に移動します。その時点でのエラーメッセージの「読み取り」は、通常、目をつぶっただけでなく、目を引くものです。行またはその近くで何が間違っているかがすぐにわからない場合は、実際にメッセージを読みます。このワークフローは、その場でエラーを強調表示するIDEまたはツールを使用するとさらに良くなり、小さな変更のみを考慮するというカールビーレフェルトの提案を自動的に実行します。

もちろん、エラーメッセージは常に適切な行を指しているわけではありませんが、適切な根本原因も指し示していない場合が多いため、エラーメッセージを完全に理解することでさえも助けになりません。適切な行を見つけることに関して、どのエラーメッセージがより信頼できるのかを知るのに時間はかかりません。

一方で、初心者が犯す可能性が高いエラーのほとんどは、コンパイラーの助けを必要とせずに、経験豊富なプログラマーにとって痛々しいほど明白です。一方で、初心者にはそれほど明白ではありません（多くの人が明白になりますが、ほとんどの間違いは愚かな間違いです）。この時点で、私はロバート・ハーベイに完全に同意します。初心者は単に言語に精通する必要があります。これを避けることはできません。なじみのない概念を参照している、または意外と思われるコンパイラエラーは、言語の知識を深めるためのプロンプトと見なされるべきです。同様に、コンパイラーが文句を言っているのに、コードが間違っている理由がわからない場合も同様です。

繰り返しますが、コンパイラー・エラーを利用するためのより良い戦略が必要であるというロバート・ハーベイに同意します。上記のいくつかの側面を概説しましたが、Robert Harveyの答えは他の側面を提供します。あなたの友人がそのような「用語集」で何をしたいのかさえ明確ではなく、そのような「用語集」が実際にあなたの友人にとって大いに役立つことはほとんどありません。コンパイラーのメッセージは、言語^1の概念を紹介する場所ではないことは確かであり、「用語集」はそれほど良い場所ではありません。エラーメッセージの意味が明快に説明されていても、問題を修正する方法はわかりません。

¹ ElmやDhall（およびおそらくRacket）のようないくつかの言語、および言語のいくつかの「初心者向け」実装は、これを試みます。このように、異なる実装を使用するというMSaltersのアドバイスは直接関連しています。私は個人的にそのようなことは説得力がなく、正しい問題に向けられたものではないと感じています。これは、より良いエラーメッセージを作成する方法がないと言うことではありませんが、私にとっては、コンパイラの信念とそれらの信念の基礎を明確にすることを中心に展開する傾向があります。

それでは、初心者プログラマはコンパイラエラーメッセージを理解するという課題にどのように取り組むべきでしょうか？具体的には、CとGCCの組み合わせで？

友だちに、理解できないエラーが発生したときに次のことを行うように伝えます。

• 最後の正常なビルド以降に追加されたコードを削除/コメントします。
• その小さな部分を元に戻してコンパイルします
• エラーが発生するまで繰り返します

コンパイラーのエラーは、コンパイラーがコードについて理解していないことのみを伝え、コードの何が問題なのかを知らせません。このアプローチは、エラーをグーグルで調べていくつかのドキュメントまたはStackOverflowの投稿を読むのとほぼ同じ時間を要しますが、あなたが間違っているのが何であるかをよりよく理解できます。

また、ビルドに数分かかるプロジェクトで作業を開始するまで、頻繁にコンパイルします。他のコードを追加しすぎる前にエラーを見つけると、非常に役立ちます。

最後に、一度に1つの作業を行うように指示し、間にコンパイルせずに複数のファイルで作業しないでください。一度に複数の依存関係を導入しないでください。

別の手法として、友人がさまざまなエラーメッセージに遭遇したときに、時間をかけて独自の用語集を作成する方法があります。多くの場合、何かを学ぶための最良の方法はそれを教えることです。もちろん、用語集が完成する頃には、おそらく彼はそれをもう必要としないでしょう。

GCCでの私の個人的な経験では、各エラーメッセージは「通常の」一連のミスに関連しています。たとえば、GCCが「＆を忘れた」と言った場合、通常は括弧を忘れていたことを意味します。もちろん、どのエラーがどのエラーメッセージに対応するかはプログラマーに依存します。これは、友人が自分の用語集を書くもう1つの正当な理由です。