どこでもデータチェックを導入するのに適したコードスタイルですか？

プロジェクトのサイズが十分に大きいので、頭の中ですべての側面を維持することはできません。その中でいくつかのクラスと関数を扱っており、データを渡しています。

時間の経過とともにエラーが発生し続けることに気づきました。別の関数にデータを渡すときに、データの正確な形式を忘れてしまったためです（たとえば、ある関数が文字列の配列を受け入れて出力し、別の関数は後で記述します）。辞書などに保持されている文字列を受け入れるため、操作している文字列を配列に入れてから辞書に入れるように変換する必要があります）。

どこがどこでどこが壊れているのかを常に把握する必要がないように、私は各関数とクラスを「分離されたエンティティ」として扱うようになりました。場合によっては、データが間違った形式で指定されている場合は、データを再キャストします。

これにより、渡すデータがすべての関数に「適合」することを確認するために費やす時間が大幅に短縮されました。クラスと関数自体が、入力に問題がある場合に警告を発し（場合によってはそれを修正することもあり）、デバッガーを使用してコード全体を処理し、問題が発生した場所を特定する必要があります。

一方、これによりコード全体も増加しました。
私の質問は、このコードスタイルがこの問題の解決に適切かどうかです。
もちろん、最善の解決策は、プロジェクトを完全にリファクタリングし、データがすべての機能に対して均一な構造を持っていることを確認することです。 。

（参考：私はまだ初心者なので、この質問が素朴だった場合は失礼します。私のプロジェクトはPythonで行われています。）

より良い解決策は、Python言語の機能とツールをより活用することです。

たとえば、関数1では、予期される入力は文字列の配列です。最初の文字列は何かのタイトルを示し、2番目の文字列は書誌参照です。関数2では、期待される入力は文字列の配列ですが、文字列の役割が逆になっています。

この問題はで軽減されますnamedtuple。それは軽量であり、配列のメンバーに簡単な意味上の意味を与えます。

言語を切り替えずに自動型チェックの利点を活用するには、型ヒントを利用できます。優れたIDEでは、これを使用して、何かばかげたことを通知できます。

また、要件が変更されたときに関数が古くなるのではないかと心配しているようです。これは自動テストで検出できます。

手動でのチェックが適切であるとは決して言えませんが、使用可能な言語機能をより適切に使用することで、この問題をより保守可能な方法で解決できます。

OK、実際の問題はこの回答の下のコメントに記載されています：

たとえば、関数1では、予期される入力は文字列の配列です。最初の文字列は何かのタイトルを示し、2番目の文字列は書誌参照です。関数2では、期待される入力は文字列の配列のままですが、文字列の役割が逆になります

ここでの問題は、順序が意味を表す文字列のリストの使用です。これは本当にエラーが発生しやすいアプローチです。代わりにtitle、およびという名前の2つのフィールドを持つカスタムクラスを作成する必要がありますbibliographical_reference。そうすれば、それらを混同することはなく、将来この問題を回避できます。もちろん、すでに多くの場所で文字列のリストを使用している場合、これにはいくつかのリファクタリングが必要ですが、私を信じて、長期的には安くなるでしょう。

動的型付け言語での一般的なアプローチは「ダックタイピング」です。つまり、渡されるオブジェクトの「型」は本当に気にせず、呼び出すメソッドをサポートするかどうかだけを気にします。あなたのケースでは、bibliographical_reference必要なときに呼び出されたフィールドを読み取るだけです。渡されたオブジェクトにこのフィールドが存在しない場合、エラーが発生し、関数に誤ったタイプが渡されたことを示します。これはどんなタイプチェックでも良いです。

まず第一に、あなたが現在経験しているのはコードのにおいです - コードのにおいに気づくとすぐに-そして簡単に- においを意識するようになる原因を思い出し、「精神的な」鼻を磨くようにしてください根本的な問題を修正できます。

どこがどこでどこが壊れているのかを常に把握する必要がないように、各関数とクラスを「分離されたエンティティ」として扱い始めました。これは、正しい入力を与える外部コードに依存できず、入力チェック自体を実行する必要があるという意味です。

防御プログラミングは、この手法と呼ばれるもので、有効でよく使用されるツールです。ただし、すべてのものと同様に、適切な量を使用することが重要です。チェックが少なすぎると、問題がキャッチされず、多すぎてコードが肥大化します。

（または、データが誤った形式で指定されている場合は、データを再キャストします）。

それはあまり良い考えではないかもしれません。プログラムの一部が誤ってフォーマットされたデータを使用して関数を呼び出していることに気付いた場合は、FIX THAT PART、呼び出された関数を変更して、不良データをダイジェストできるようにします。

これにより、渡すデータがすべての関数に「適合」することを確認するために費やす時間が大幅に短縮されました。クラスと関数自体が、入力に問題がある場合に警告を発し（場合によってはそれを修正することもあり）、デバッガーを使用してコード全体を処理し、問題が発生した場所を特定する必要があります。

コードの品質と保守性を改善することは、長期的には時間の節約になります（その意味で、一部の関数に組み込まれた自己修正機能に対して再度警告する必要があります。これらはバグの潜伏する原因となる可能性があります。プログラムはクラッシュせず、書き込みも正しく機能するわけではありません...）

最後にあなたの質問に答えるには：はい、防御的プログラミング（つまり、提供されたパラメーターの有効性の検証）は-健全な程度で-良い戦略です。とは言っても、あなたが言ったように、あなたのコードは一貫性がなく、匂いのある部分をリファクタリングするためにある程度の時間を費やすことを強くお勧めします-あなたはいつもクリーンなコードについて心配したくないので、より多くの時間を費やしていると言いました新機能よりも「掃除」...あなたはバグを潰しにクリーンなコードを保っていないから、「保存」2倍の時間を費やす可能性があり、新しい機能を実装するハードの時間を持つことになりますきれいに、あなたのコードを維持していない場合は- 技術的負債の缶あなたをつぶします。

大丈夫。私はFoxProでコードを作成していましたが、ほとんどすべての大きな関数にTRY..CATCHブロックがありました。今、私はJavaScript / LiveScriptでコーディングし、「内部」または「プライベート」関数のパラメーターをほとんどチェックしません。

「どれだけチェックするか」は、コードのスキルに依存するよりも、選択したプロジェクト/言語に依存します。