エラーをキャッチするためにコンパイラに依存するよりも優れた戦略はありますか？
私はCとC++でプログラミングをしてきましたが、専門家にはほど遠いと思います。しばらくの間、単体テスト、テスト駆動設計、コードレビューなど、さまざまな戦略を使用してコードを開発してきました。
私が最初のプログラムをBASICで書いたとき、それらが実行されないことを見つける前に長いブロックを入力しました、そしてそれらはデバッグするのに悪夢でした。それで私は少し書いてそれをテストすることを学びました。
最近では、小さなコードを繰り返し記述してから、コンパイラーを使用してすべての間違いを見つけることがよくあります。タイプミスがあれば問題ありませんが、コンパイルするためだけにパラメータタイプなどを調整し始めると、デザインを台無しにする可能性があります。また、構文のチェックにのみ使用する必要がある場合、コンパイラーは設計プロセスに忍び寄っているようです。
私のプログラムをより良くするためにコンパイラに過度に依存する危険がここにあります。これよりも優れた戦略はありますか？
少し前に、あるタイプのCコンパイラを開発している会社に関する記事をぼんやりと覚えています。この記事では、追加のヘッダーファイルでもプロトタイプが指定されています。 API定義の不整合は、異なる方法で2回定義する必要がある場合、簡単に見つけられるという考えでした。
コンパイルするように調整しないでください。 正しいになるように調整します。パラメータタイプが一致しないように「設計」されている場合、設計者は何をしているのかわかりません。
コンパイラに依存したくない場合は、言語の知識を向上させてください。定義と宣言の構造を調べ、コンパイルする前にエラーがないかどうかを確認してください。そして、コードレビューを使用します。
その余分なプロトタイプのアイデアは悪いように聞こえます。一度間違って設計した場合、2番目の設計が間違って設計されないようにするにはどうすればよいですか？また、同じことに対して異なるフォーマット/パラダイムなどを使用すると、人々を混乱させる可能性があります。エラーをキャッチするために設計作業を2倍にするのではなく、最初に設計を正しく行うことに集中できるように、すべての人が主要な形式を理解していることを確認します。他のすべてのように、デザインはリファクタリングする必要がありますが、最初に2回行うことはあまり意味がないと思います。
正直なところ、私はあなたの目標は常に最初にコンパイルするプログラムを書くことであるべきだと信じています。これは難しいことであり、おそらく頻繁には起こらないと思いますが、それでもあなたの目標であるはずです。ソフトウェアをピースハードウェアと考えてください。コードを再コンパイルするのは非現実的にコストがかかると自分自身に信じさせてください（ボードの再製造など）。コンパイラーはデバッガーではないため、そのように扱うべきではありません。
コンパイラはすべての間違いを見つけることができないので、それができるふりをする意味はありません。見つけることができるのは、構文エラーとタイプミスだけです。仕事のその部分を実行させるのは十分ですが（最近では、コンパイルを実行する前に、環境自体が99％をキャッチします）、それがすべてのエラーではないことを完全によく知っています。
何を書くべきかを私に伝えるためにその種の情報に頼るのは、doubleをfloatに自動的に変換できないというようなものを受け取ったときだけです-データを送信している場所がfloatを期待している場合（そしてそれ以降私が現在行っているのは、まさにこれを行うXNAライブラリで遊んでいることです）そしてソースは（C＃数学ライブラリの場合のように）doubleを返し、それからあなたは単に変換する必要があります。
コンパイラはツールです。すべてのツールと同様に、それらは悪用される可能性があります。
言語を初めて使用するときは、コンパイラを盲目的に使用してプログラムをテストしても問題はありません。それは本質的に学習がどのように機能し、推測し、チェックするかです。しかし、それはあなたがそのようにコーディングし続けるべきだという意味ではありません。
プログラムを頭の中でコンパイルできるように、言語を十分に理解することが最も重要です。そうすれば、コンパイラーが終了するのを待つ時間が少なくなります。
私は、プログラムが常にコンパイル可能であるコードの数行/ブロック内にあることがおそらく最善だと言います。
最近のIDEのほとんどはコンパイラの問題をたくさんキャッチしており、私もこれにかなり依存するようになっていると思います。
たぶん、テキストファイルとコマンドラインコンパイラに戻りますか？