条件を重複してチェックするのは悪いスタイルですか？

コードの中で、特定の条件を何度もチェックしていることがよくあります。

簡単な例を挙げましょう。「a」で始まる行、「b」で始まる行、およびその他の行を含むテキストファイルがあり、実際には最初の2種類の行のみを処理したいとします。私のコードは次のようになります（Pythonを使用しますが、擬似コードとして読み取ります）。

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a")):
        # do stuff
    elif (line.startsWith("b")):
        # magic
    else:
        # this else is redundant, I already made sure there is no else-case
        # by using clear_lines()
# ...

ここでこの状態をチェックするだけでなく、他の関数などでもチェックすることを想像できます。

それをノイズと考えますか、それとも私のコードに何らかの価値を加えますか？

これは非常に一般的な方法であり、これに対処する方法は、高次のフィルターを使用することです。

基本的に、フィルター処理するリスト/シーケンスと共に関数をフィルターメソッドに渡し、結果のリスト/シーケンスには必要な要素のみが含まれます。

私はpython構文に慣れていません（ただし、上記のリンクにあるような関数が含まれています）が、c＃/ f＃では次のようになります。

c＃：

var linesWithAB = lines.Where(l => l.StartsWith("a") || l.StartsWith("b"));
foreach (var line in linesWithAB)
{
    /* line is guaranteed to ONLY start with a or b */
}

f＃（ienumerableを想定、そうでない場合はList.filterが使用されます）：

let linesWithAB = lines
    |> Seq.filter (fun l -> l.StartsWith("a") || l.StartsWith("b"))

for line in linesWithAB do
    /* line is guaranteed to ONLY start with a or b */

したがって、明確にするために、テスト済みのテスト済みのコード/パターンを使用すると、スタイルが悪くなります。つまり、clear_lines（）を介して表示される方法でメモリ内のリストを変更すると、スレッドの安全性と、並列処理の可能性が失われます。

最近、Motorola Sレコード形式を使用してファームウェアプログラマーを実装する必要がありました。時間的なプレッシャーがあったため、最初のドラフトでは冗長性を無視し、アプリケーションで実際に使用する必要があるサブセットに基づいて簡略化しました。それは私のテストに簡単に合格しましたが、他の誰かがそれを試みたとたんに激しく失敗しました。問題が何であるか手掛かりはありませんでした。それは完全に通りましたが、最後に失敗しました。

そのため、問題がどこにあるかを絞り込むために、すべての冗長なチェックを実装するしかありませんでした。その後、問題を見つけるのに約2秒かかりました。

正しい方法を実行するには、おそらく2時間余分にかかりましたが、トラブルシューティングのために他の人の時間を1日も無駄にしました。いくつかのプロセッササイクルが1日の無駄なトラブルシューティングに値することは非常にまれです。

そうは言っても、ファイルの読み取りが関係している場合、ファイル全体をメモリに読み込んでメモリで処理するのではなく、ファイルを読み込んで一度に1行ずつ処理するようにソフトウェアを設計する方が多くの場合有益です。そうすれば、非常に大きなファイルでも機能します。

else場合に応じて例外を発生させることができます。この方法は冗長ではありません。例外は発生するはずのないことですが、とにかくチェックされます。

clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a)):
        # do stuff
    if (line.startsWith("b")):
        # magic
    else:
        throw BadLineException
# ...

で契約による設計、一つはそのマニュアルに記載されている各機能は、その仕事をする必要があります推測します。したがって、各関数には事前条件、つまり関数の入力の条件と、事後条件、つまり関数の出力の条件のリストがあります。

関数は、入力が事前条件を尊重している場合、出力は事後条件で記述されているとおりであることをクライアントに保証する必要があります。少なくとも1つの前提条件が守られていない場合、関数は必要なことを実行できます（クラッシュ、結果を返すなど）。したがって、事前条件と事後条件は、関数のセマンティックな説明です。

契約のおかげで、関数はクライアントが正しく使用していることを確認し、クライアントは関数が正しく機能していることを確認しています。

一部の言語では、ネイティブまたは専用のフレームワークを通じてコン​​トラクトを処理します。他の人にとっては、@ Lattywareが言ったように、アサートのおかげで事前条件と事後条件をチェックするのが最善です。しかし、私の考えでは、この概念は（人間の）ユーザーの入力に対する保護に重点を置いているため、私はその防御的プログラミングとは呼びません。

コントラクトを悪用すると、呼び出された関数が完全に機能し、二重チェックが不要になるか、呼び出された関数が機能しなくなり、呼び出した関数が意図したとおりに動作するため、冗長なチェック状態を回避できます。

難しいのは、どの機能が何に責任があるかを定義し、これらの役割を厳密に文書化することです。

最初は、clear_lines（）は実際には必要ありません。行が "a"でも "b"でもない場合、条件文はトリガーされません。これらの行を削除したい場合は、elseをclear_line（）にしてください。現状では、ドキュメントを2回パスしています。最初にclear_lines（）をスキップして、foreachループの一部として実行すると、処理時間が半分になります。

スタイルが悪いだけでなく、計算も悪い。

無効な文字列（たとえば、出力デバッグテキスト）を見つけて実際に何かを実行したい場合は、それで問題ありません。いくつかの追加の行と、何らかの未知の理由で機能が停止した数か月後の出力を見て、理由を確認できます。

ただし、無視しても安全である場合、または無効な文字列が取得されないことが確実な場合は、追加のブランチは必要ありません。

個人的には、私は常に予期しない状況に対して少なくともトレース出力を行うことを心がけています。出力に添付されたバグがあり、何が問題だったかを正確に伝えるときに、非常に簡単です。

... "a"で始まる行、 "b"で始まる行、およびその他の行を含むテキストファイルがあり、実際には最初の2種類の行のみを処理したいとします。私のコードは次のようになります（Pythonを使用しますが、擬似コードとして読み取ります）。

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if ...

構造が嫌いif...then...elseです。私は問題全体を回避します：

process_lines_by_first_character (lines,  
                                  'a' => { |line| ... a code ... },
                                  'b' => { |line| ... b code ... } )