認知のオーバーヘッドを減らすために、コードの背後にある目的は「イディオマティック」ですか？

私は誰かにコードを書いた方法が理解しにくいことを説明しようとしています。そして、あなたがそれをリファクタリングすれば読みやすくなります。私が運転しているこのスタイルのコードは、一般に「イディオマティック」コードと呼ばれます。

しかし、イディオムコードというフレーズは、道徳的な正しさの手荷物をもたらします。これは、人々にコーディングスタイルを変更させる大きな動機ではありません。これをより積極的に表現する方法は、共通のスタイルに従うコードですが、群れのメンタリティの推論として出くわす批判的な思想家に対するものです。

人々がコードを変更する動機を与える方法でこのアイデアを説明する方法は次のとおりです。

• リーダーの認知オーバーヘッドを減らすような方法でコードを記述します（たとえば、これが第1種のベクトルか第5種のベクトルかを思い出せません）
• 意図を理解しやすくするコード（たとえば、このベクトルは何のためですか？）

（余談ですが、最初の出版前のThe Joy of Clojureの本には、「Idiomatic Clojure」というタイトルのドラフトがありました。そのため、読者に「喜び」をもたらすために、コードを「イディオマティック」にする理由に思えます。 ）。

私の質問は次のとおりです。認知オーバーヘッドを減らすために、コードの背後にある目的は「イディオマティック」ですか？

まず、「イディオマティック」という用語に「道徳的正しさ」が含まれているかどうかはわかりません。平野辞書の定義は単純です

特定の言語または方言に特有または特徴的：慣用的なフランス語。

はい、一般的に、特に標準ライブラリとプロジェクトが必要とするサードパーティライブラリがすべて（実質的に）すべて慣用であるインターフェイス定義では、慣用コードは認知オーバーヘッドを削減します。

ただし、セールスポイントとして、認知オーバーヘッドを減らすことがあなたに何をもたらすかに焦点を当てます。プログラマーは、独自のスタイルで記述されたコードを解いて、1つだけ微妙に外れている箇所やエッジケースを誤って処理している箇所を見つけようとしないため、ミスを見つけやすくなります。他の人のコードをレビューするのが簡単になり、チームが構文について議論するのではなく、実際の問題を特定する実際のレビューを行う可能性が高くなります。

認知のオーバーヘッドを削減するだけでなく、通常、慣用的なコードはより効率的なコードです。言語は特定の方法で問題に取り組むように設計されているため、特定の言語のほとんどのイディオムは進化します。使用しているコンパイラーまたはインタープリターは、最適化を慣用的なコードに集中させます。たとえば、再帰がコードの一部を構成する慣用的な方法である言語を使用する場合、コンパイラが末尾再帰を実装していることをほぼ確実にすることができます。再帰が非慣用的である言語を使用している場合、その可能性ははるかに低くなります。末尾再帰をどこにでも実装することはできませんが、ほとんどのコンパイラライターは、一般的には発生しないことに焦点を当てることはありません。

イディオムには道徳的な意味合いがあるという考えがどこで得られるのかわかりません。イディオムは物事を表現するための単なる方法です。それらは、個々の単語やフレーズよりも大きなスケールのパターンです。

オオカミにhowえる必要があると言ったら、それはよく知られているドイツ語のイディオムですが、あなたは私が何を意味したのか分かりません。OTOH、ローマにいるとき、ローマ人がそうするように言ったなら、私が適切な英語のイディオムを使ったので、あなたが私が話していることをすぐに知っているでしょう。

コンピューターの言語も同じです。

実際、プログラミングの世界では「イディオム」の別名は「実装パターン」です。これは、アイデアをパターンのアイデアに関連付けます。パターンのアイデアは、アーキテクト（ビットとバイトではなくレンガとモルタル）クリストファーアレクサンダーから来ています。ほとんどのプログラマーはデザインパターンについて知っており、一部のプログラマーはアーキテクチャパターンについて知っています。これは、デザインパターンよりも規模が大きいパターンです。イディオムは、デザインパターンよりも小さなスケールのパターンです。

ほとんどの言語は、意図的に特定のスタイルに適しています。そのスタイルで書かれたコードは慣用的なものです。ランタイム環境の選択が使用可能な言語の選択肢を狭めるという状況的事実を過ぎて見た場合、手元の問題は言語の特定のイディオムで表現しやすいため、言語を選択する必要があります。

ほとんどの人はそれを取得しません。たとえば、多くのJavaプログラマーは、JavaScriptを記述しなければならない場合（同じJavaを記述してクロスコンパイルすることもできます）、同じスタイルを維持しようとし、ある程度成功します-JavaScriptでJavaイディオマティックなコードを記述します-しかし、彼らは常にJavaScriptと戦う感覚を持っています。特定の機能が欠落しているか、それらをエミュレートするのが難しいことがわかりました。

慣用的なコードは良いです。部外者にとっては難しいですが、彼らは学ぶことができます。最終的に、コードは何年も維持する必要があるため、基になるプログラムを平易に表現できるイディオム内の言語を見つけることができれば、それはあなたがすべきことです。

イディオムの過剰使用（または基礎となる言語機能）などが間違いなく存在することを明確にしましょう。C ++テンプレートを使用してコンパイル時にアプリケーションロジックの重要な部分を実行する場合、または完全なLispプログラムが実際の予測不可能な方法で実際のものに展開するマクロの呼び出しである場合、単純な問題のJavaソリューションがFizzBu​​zzEnterpriseEditionの割合...あなたはそれを間違っている。

人々は、コードは読みやすいものでなければならないと言います。それは真実の半分にすぎません。それは理解しやすいものでなければなりません。それには、抽象化の適切な使用が必要です。ほとんどのものと同様に、それは適切なバランスを打つことの問題です。