機能の純度がベストプラクティスと見なされるかどうか、またはそれが好みやプログラミングスタイルに依存するかどうかについて、コンセンサスがあるかどうかを知りたいです。言い換えれば、これは議論の余地がありますか、それともこれは効果的に決定されていますか？私が見つけたすべての情報は、それが不利な点のない美徳であることを示唆しています。これは本当ですか？
地域の実践コミュニティのベストプラクティスのリストをまとめたいと思います。また、これをどの程度含めるべきかを知りたいと思います。
2 に答える
4
goto を回避するのと同じように、変異やその他の副作用を回避するのが最善です。つまり、便利な場合もありますが、ほとんどの場合、それほど困難なく、より構造化されたソリューションに置き換えて置き換えることができません。
もちろん、その多くは使用している言語とライブラリに依存します。副作用のないプログラミングは、それ用に設計されていない言語 (つまり、ほとんどすべての主流言語) では非常に不便です。
特定の言語の制約とは関係なく、変更可能なデータ構造や、big-O 複雑度クラスを変更せずに関数型アルゴリズムに置き換えることが困難な命令型アルゴリズムの場合もあります。ほとんどの関連するケースでは、最近では優れた解決策が知られていますが、時にはトリッキーであり、場合によっては活発な研究が行われています.
とは言っても、純度を失うことなく副作用が発生する可能性は十分にあります. たとえば、Haskell のモナドの使用を参照してください。
于 2012-11-26T18:09:26.363 に答える
3
原則として、コードの意図しない複雑さを減らす必要があります。これは議論の余地がありません。
複雑さを軽減する最善の方法の 1 つは、コード内の情報チャネル (あるコンポーネントから別のコンポーネントに情報が「漏れる」可能性がある方法) を制限することです。これにより、コードがよりシンプルでモジュール化され、テストしやすく、使いやすく、保守しやすくなります。
変更可能な変数とその他の副作用は、定義上、情報チャネルであり、関数の引数と結果の通常のチャネルと比較して比較的「隠されている」ものです。それらを使用したコードはふるいのようなものであり、変更可能な変数を介して、一時的で時間に依存する方法で、コードの内外に情報が漏洩します。
グローバルに可視の変更可能な変数は、コード ベース全体で (潜在的に) 情報を漏らし、管理する必要のある多くの複雑な情報チャネルを追加するため、最悪です。ローカル スコープの変更可能な変数は、せいぜい数行の一時的な情報しか漏らしません。前者は避け、後者には注意する必要があります。
したがって、複雑さを最小限に抑えてモジュール性を高めるという目標では、不要な複雑さでコードを汚染するため、漏れやすい副作用を避ける必要があります。変更可能な変数やその他の副作用を避けることは、従うべき優れた経験則です。
于 2012-11-26T21:21:57.510 に答える