複雑なコードベースでは、副作用の複雑な相互作用は、私が推論する最も難しいものです。脳の働き方を考えれば、個人的にしか話せません。副作用や永続的な状態、入力の変化などにより、個々の機能で「何が」起こっているかだけでなく、「いつ」「どこで」正しいことを理由に考える必要があります。
「何」だけに集中することはできません。呼び出し元が間違ったタイミングで、間違ったスレッドから、間違った方法で呼び出すことでそれを誤用する可能性があるため、副作用を引き起こす関数を徹底的にテストした後、それを使用するコード全体に信頼性の空気を広めるという結論を出すことはできません注文。一方、副作用を引き起こさず、入力が与えられると（入力に触れることなく）新しい出力を返す関数は、この方法で誤用することはほとんど不可能です。
しかし、私は実用的なタイプだと思う、または少なくともそうしようとしています。そして、コードの正確さを推論するために、すべての副作用を最小限に抑える必要はないと思います（少なくともC）のような言語でこれを行うのは非常に難しいと思います。正確性について推論するのが非常に難しいと感じるのは、複雑な制御フローと副作用の組み合わせがある場合です。
複雑な制御フローは、本質的にグラフのようなものであり、多くの場合、再帰的または再帰的です（イベントキュー、たとえば、イベントを直接再帰的に呼び出すのではなく、本質的に "再帰的な"）。実際にリンクされたグラフ構造をトラバースするプロセス、または処理するイベントの折mixture的な混合物を含む不均一なイベントキューを処理するプロセスで、コードベースのさまざまな種類の部分とさまざまな副作用を引き起こすすべてにつながります。最終的にコードで終わるすべての場所を描画しようとすると、それは複雑なグラフに似ており、潜在的にその瞬間にそこにいたとは予想していなかったグラフのノードを持つ可能性があります副作用を引き起こす
関数型言語は非常に複雑で再帰的な制御フローを持つことができますが、その過程でさまざまな折side的な副作用が発生するわけではないため、結果は正確さの観点から非常に簡単に理解できます。複雑な制御フローが折side的な副作用に出会ったときだけ、何が起こっているのか、それが常に正しいことをするかどうかを理解しようとするのは頭痛の種になります。
そのため、これらのケースがある場合、そのようなコードの正確性について非常に自信を持って感じることは不可能ではないにしても、非常に困難であることがよくあります。したがって、私に対する解決策は、制御フローを簡素化するか、副作用を最小化/統合することです（統合することにより、システムの特定の段階で多くの事柄に1種類の副作用のみを引き起こし、2つまたは3つまたはダース）。存在するコードの正確性と導入する変更の正確性について、simpleton brainが自信を持てるようにするために、これら2つのことのいずれかが必要です。副作用が制御フローとともに均一で単純な場合、副作用の原因となるコードの正確性について自信を持つことは非常に簡単です。
for each pixel in an image:
make it red
そのようなコードの正確さについて推論するのは非常に簡単ですが、主に副作用が非常に均一であり、制御フローが非常に単純であるためです。しかし、次のようなコードがあったとしましょう：
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
次に、これは非常に単純化された擬似コードであり、通常、はるかに多くの機能とネストされたループ、および継続する必要のあるもの（複数のテクスチャマップ、ボーンの重み、選択状態など）が含まれますが、擬似コードでさえも非常に困難です複雑なグラフのような制御フローと進行中の副作用の相互作用のため、正確さについての理由。そのため、それを単純化するための1つの戦略は、処理を延期し、一度に1種類の副作用にのみ焦点を当てることです。
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
...単純化の1つの反復としてのこの効果に対する何か。つまり、データを複数回通過することは間違いなく計算コストを招きますが、副作用と制御フローがこの均一でシンプルな性質を帯びているため、そのような結果のコードをより簡単にマルチスレッド化できることがよくわかります。さらに、各ループは、接続されたグラフを走査して副作用を引き起こすよりもキャッシュフレンドリーにすることができます（例：並列ビットセットを使用して、走査する必要があるものをマークし、ソートされた順序で遅延パスを実行できるようにしますビットマスクとFFSを使用）。しかし、最も重要なことは、バグを引き起こさずに変更するだけでなく、正確さの点でも2番目のバージョンのほうがはるかに簡単に推論できることです。そのため'
結局のところ、ある時点で副作用が発生する必要があります。そうでなければ、どこにも行かないデータを出力する関数が必要になります。多くの場合、ファイルに何かを記録し、画面に何かを表示し、この種のソケットを介してデータを送信する必要がありますが、これらはすべて副作用です。しかし、余分な副作用の数を確実に減らすことができ、制御フローが非常に複雑な場合に発生する副作用の数も減らすことができます。