エラーをキャッチするためにコンパイラーに依存するよりも良い戦略はありますか？

私はしばらくCとC ++でプログラミングをしてきましたが、私は専門家とは程遠いです。しばらくの間、単体テスト、テスト駆動設計、コードレビューなど、さまざまな戦略を使用してコードを開発してきました。

私がBASICで最初のプログラムを書いたとき、実行できないことを見つける前に長いブロックを入力しましたが、デバッグするのは悪夢でした。だから私は少し書き、それをテストすることを学びました。

最近では、小さなコードを繰り返し記述してから、コンパイラーを使用してすべての間違いを見つけることがよくあります。タイプミスを拾えば問題ありませんが、コンパイルするためにパラメータタイプなどの調整を開始すると、デザインを台無しにすることができます。また、構文のチェックにのみ使用する必要がある場合に、コンパイラーが設計プロセスに侵入しているようです。

私のプログラムをより良くするために、コンパイラーに過度に依存する危険があります。これより良い戦略はありますか？

少し前に、追加のヘッダーファイルでもプロトタイプを指定したCコンパイラのタイプを開発している会社に関する記事を漠然と覚えています。異なる方法で2回定義する必要がある場合は、API定義の不整合を見つけやすくなるという考えでした。

コンパイルするように調整しないでください。正しくなるように調整してください。パラメータタイプが一致しないように「設計」されている場合、設計者は何をしているのかまったくわかりません。

コンパイラに依存したくない場合は、言語の知識を向上させてください。定義と宣言の構造を調べ、コンパイルする前に、エラーについて何を書いているかを確認してください。そして、コードレビューを使用してください。

その余分なプロトタイプのアイデアは悪いように思えます。一度間違って設計した場合、2番目の設計が間違って設計されないようにするにはどうすればよいですか？そして、同じものに異なるフォーマット/パラダイムなどを使用すると、人々を混乱させる可能性があります。エラーをキャッチするために設計作業を2倍にするのではなく、最初に設計を正しく行うことに集中できるように、すべての人が主要な形式を理解していることを確認します。他のすべてのように、デザインはリファクタリングする必要がありますが、最初から2回行うのは理にかなっているとは思いません。

正直なところ、あなたの目標は常に最初にコンパイルするプログラムを書くことであるべきだと私は信じています。これは難しいことであり、おそらく頻繁に発生することはないと思いますが、それでも目標にする必要があります。ソフトウェアをハードウェアの一部と考えてください。（ボードの再製造のように）コードを再コンパイルするのは非現実的にコストがかかると信じてください。コンパイラはデバッガではないため、そのように扱うべきではありません。

コンパイラーはすべての誤りを見つけることができないため、それを可能にするふりをしても意味がありません。見つけることができるのは構文エラーとタイプミスだけです。それは私が仕事のその部分をやるのに十分です（最近では、コンパイルをヒットする前に環境自体がそれらの99％をキャッチします）が、私はそれがすべてのエラーではないことを完全に知っています。

そのような情報に頼って何を書くべきかを教えてくれるのは、倍精度浮動小数点数を自動的に倍精度浮動小数点数に変換できないというメッセージが表示されたときだけです。私が現在やっていることは、これを正確に行うXNAライブラリで遊んでいます）、ソースは倍精度浮動小数点数を返します（C＃数学ライブラリの場合のように）、変換する必要があります。

コンパイラはツールです。すべてのツールと同様に、悪用される可能性があります。

最初に言語を使い始めるときは、コンパイラを盲目的に使用してプログラムをテストしても問題はありません。それは本質的に学習の仕組み、推測、チェックの方法です。ただし、これはそのようなコードを継続する必要があるという意味ではありません。

プログラムを頭の中でコンパイルできるように十分に言語を理解することは、あなたの最善の利益です。そうすれば、コンパイラが完了するのを待つ時間が少なくなります。

私は、プログラムが常にコンパイル可能であるコードの数行/ブロック内にあることがおそらく最善だと言います。

最近のほとんどのIDEは多くのコンパイラー問題をキャッチしており、私もこれにかなり依存するようになったと思います。

テキストファイルやコマンドラインコンパイラに戻ってみませんか？