シンプルさは常に可読性を向上させますか？

最近、私は会社のために一連のコーディング標準を開発していました。（私たちは会社の新しい言語に分岐する新しいチームです。）

最初のドラフトでは、コーディング標準の目的を、読みやすさ、保守性、信頼性、およびパフォーマンスの向上として設定しました。（書き込み可能性、移植性、コスト、以前の標準との互換性などを無視しました。）

このドキュメントを書いているときの私の目標の1つは、コードのシンプルさのアイデアを推し進めることでした。アイデアは、1行につき1つの関数呼び出しまたは操作のみが必要であるというものでした。私の希望は、これにより読みやすさが向上することでした。以前の言語から引き継いだアイデアです。

ただし、このプッシュの背後にある仮定に疑問を投げかけました。

シンプルさは常に読みやすさを向上させますか？

より単純なコードを記述すると読みやすさが低下する場合はありますか？

それは明らかなはずですが、「シンプル」というのは「書くのが簡単」という意味ではなく、1行あたりの処理が少ないことを意味します。

「シンプル」は使い古された言葉です。「読みやすい」とは「理解しやすい」と有益に定義できます。その場合、定義によってシンプルさを増やせば読みやすさが向上しますが、これはあなたが言っていることではないと思います。これについては別の場所で書き ましたが、一般的には、より抽象的（この場合、より少ない概念でより多くの現象を表現できる）またはより具体的（この場合、概念はそれほど背景を必要としない）そもそも理解すべき知識）。私は、視点に応じて、より具体的な概念よりも抽象的な概念を合理的に単純に、またはその逆に合理的に呼ぶことができると主張しています。これは、「抽象」と「

例として、少し前に書いたHaskellコードを使用します。私はstackoverflowの上で質問をし、各桁が違う基盤を持っている可能性がでカウンターを計算するために、リストモナドの使用に関する。私の最終的な解決策（Haskellをあまり知らない）は次のように見えました：

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

答えの1つはこれを次のように減らしました：

count = mapM (enumFromTo 0)

どちらが理解しやすい（読みやすい）かは、読者が（抽象的な）モナド操作（そして、そのために、ポイントのないコード）にどれだけ慣れているかに完全に依存します。これらの抽象的な概念に非常に満足している読者は、（短い）より抽象的なバージョンを読むことを好み、それらの操作に不慣れな読者は、（長い）より具体的なバージョンを読むことを好みます。どのバージョンがより読みやすいかについて誰にも当てはまる答えはありません。

コーディング標準が「読みやすさ、保守性、信頼性、およびパフォーマンス」に関するものである場合は、それを述べてください。

反例がある状況は常に存在するため、これらのことを達成する方法を試みたり処方したりしないでください。

あなたが処方する必要があるのは、守らなければコードが壊れるようなことです。文体特性はコードを破壊せず、提案である必要があります（チームの大部分が可読性であることに同意する限り、残りは開発者の好みである必要があります（仲間の圧力が他の人がコードを読む必要があることを人々に思い出させるようにコードレビューを使用）） 。

「1行あたりのデータ」の削減、シンプルさ、読みやすさは同じではありません。信じられないほど複雑で不明瞭な文書化されていないアルゴリズムを使用して、2行ではなく1行につき1ステートメントでコーディングすれば、それほど読みやすくなることはありません。

「1行あたりのデータ」が少なくなると、コードブロックがより垂直に広がるように、大きな大きなモニターを開発者に提供する必要があります。または、小さなフォントを読んで眼精疲労を引き起こします。

読みやすさは独自のメトリックであり、多くの場合、他のより簡単に測定可能なメトリックの間で妥協が必要です。他のすべてのメトリックを事前に制約すると、妥協が不可能になり、コードが読みにくくなります。

常に？-いいえ

皮肉なことに、適切なレベルの単純さを達成することは、複雑な仕事です。鍵は節度にあると思います。シンプルさは見る人の目にもあるので、あなたがそれを過剰に考えていることに気付いたなら、それをそのままにしておくか、後で戻ってください。

個人的に、私が戻って書いたものを単純化しようとするとき、私は自分の考えを変えた領域に焦点を当てたり、欲しいものを手に入れるためにいくつかのことを試しました。通常、これらの領域は平滑化できます。その後、コードを数回パスするだけで、コードを読みやすくすることができます。コードを読みやすくするために、あちこちに飛び回ってデバッグで何が起こっているのかを把握します。

簡単にするために、次のようなコードを作成できます。

10000000000000000000000000000000000000000000

しかし、読みやすくするために、これを好むでしょう：

1e43

一方、常に科学表記法で数値を操作しない限り1000、はるかに読みやすく簡単1e3です。

これは、ほとんどどこでも見つけることができるはるかに一般的なパターンの退化した例です。非常に単純なブロックから何かを構築すると、さまざまな方法ですぐに判読不能/非効率/不良になる可能性があります。一方、一般化と再利用は、最初は難しい（「wtfはe？！書くことを意味したの1343か？」と言う人もいるかもしれません）が、長期的には大いに役立つ可能性があります。

必ずしも。複雑な操作がある場合、その複雑さはどこかに行かなければなりません。1行に表示される「スタッフ」の数を減らすことは、より多くの行を使用することを意味します。これは、ルーチンが1画面に収まらないほど高すぎる場合、実際にはコードの可読性に悪影響を及ぼします。

明快さ+標準+コードの再利用+良いコメント+良いデザイン により、読みやすさが向上します。

最近のアルゴリズムの性質とアプリケーション構造の複雑さから、単純さが常に開発者の手に渡るとは限りません。

単純なタスクを実行する単純なWebページを取り上げます。ソートルーチンを考えると、ロジックを単純化することはできませんが、コメントを付けたり、意味のある変数名を使用したり、構造化された方法で記述したりすることで、ロジックを明確にすることができます。

シンプルさは常に読みやすさを向上させますか？

いいえ。1行で複数の単純なことを行う方が、複数の行を使用するよりも複雑ではないケースをたくさん見ました。

少ないコードと簡単なコードの間にはトレードオフがあります。

一般に、より少ない行で実行する方が確実でない限り、より単純なコードを使用することをお勧めします。「複雑すぎる」コードよりも「冗長すぎる」コードの方がずっといいです。

「物事をできるだけシンプルに、しかしシンプルにしない」 -アルバート・アインシュタインのしばしば言い換え

シンプルさがすべてを改善します。もちろん、単純さの異なる値のために。コードの行が減っていませんか？多分。小さい実行可能ファイルですか？おそらく。あなたのチームが同意する必要があるものですか？絶対に。

シンプルさは常に読みやすさを向上させますか？はい。行ごとに1つのステートメントは常に単純ですか？いいえ。ごく少数の言語には、三項演算子があります。三項演算子は、ひとたび把握すると、同等のif / else割り当てよりも簡単で理解しやすいものです。

1行に複数の変数を設定できる言語では、それを行うことは多くの場合、同等のものよりも簡単で理解しやすいです。

別の例：正規表現は多くの場合、通常は1行で実行され、正規表現のない同等の表現は非常に読みにくくなります。/ \ d {3} [-] \ d {3}-\ d {4} /は、少なくともいくつかのコメントを含む関数呼び出しと同等であり、対応する関数本体よりも理解しやすいです。

読みやすさとシンプルさは主観的な用語であり、人や状況によって異なりますが、常にではありません。

より客観的な用語は簡潔さです-いくつかの欠陥はありますが、原則として文字を数えることで数えることができます。簡潔さは単純さと読みやすさを暗示しているようですが、（少なくとも私の意見では）例外があります。

意図をより適切に表現すれば、より長い（そしておそらくより複雑な）コードも読みやすくなります。単純性の定義が意図を重視するかどうかは、別の主観的なものです。たとえば、意図をまったく参照せずに、構文構造と情報理論エントロピーの観点から複雑さを定義できます。

したがって、適切に選択されたより長い変数名は...

• 意図をより適切に表現することで読みやすさを向上させる
• 簡潔さを減らす-結局は長くなります
• 構文の単純さにはまったく影響しません-コードの構文構造は変更されていません

同様に、私は書くかもしれませんif (some_boolean == true)。同等の選択肢と比較してif (some_boolean)、これ...

• 簡潔さを減らす
• 構文のシンプルさは低下しますが、
• 意図をより適切に表現することにより、読みやすさを改善できます。

もちろん、これは大規模な抗議を引き起こします-多くの人々にとって、これは常に読みやすさを損ないます。私にとって、それはブール値のソースに大きく依存しています。たとえば、変数名（またはメソッド名など）が、値が「真の値」であることを明確に表現できない場合があります。確かに、それifはあなたに何かを伝えますが、それはまだ匂いがします。しかし、多くの人々は私をこれを信じるバカと呼ぶでしょう。

もちろん、これは全体的な主観性のさらなる証拠です。

基本的な定義が欠けています。ルートsim-plexからの単純なとは、1つのfoldを意味します。シンプルとは、1つのことを行うことを意味します。簡単、根本的な使いやすさから、近くにあることを意味します。簡単とは、手元にあることを意味します。他の回答に記載されている単純なコードの例は、正確に表示されるものではありません。

テイクrotsorの非常に大きな値の表示を。彼はこれは簡単だと言います。私の推定では、単純ではありません。それは簡単です。必要な0の数を入力するのは手近です。

10000000000000000000000000000000000000000000

読み込み可能なバージョンは簡単です。それは一つのことをします。この関数用に作成された表記目的でサイズを記述することにより、数値を表現します。

1e43

Aidanの「単純な」コードスニペットを1つのこととして説明できますか？10行のコード（コメントはカウントしません）と少なくとも7ブロック（私はそれらをカウントします）が含まれています。コメントに従うと、少なくとも4つのことを行うことがわかります！

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

しかし、このコードを書き換えるための推奨事項の1つは1つのステートメントでした。Aidanは、読者がモナドステートメント、ポインターフリーコードなどに精通する必要がある、または精通する必要があると述べています。それは問題ありません。これらの概念は、学習するために特異で独立しています。

count = mapM (enumFromTo 0)

本当にシンプルなコードは、簡単なコードよりも読みやすいことがわかります。単純なコードを理解するために、「1つのこと」を学ぶ必要があるかもしれません。ただし、常に読みやすくする必要があります。

シンプルさは常に読みやすさを向上させますか？

たぶん、少し論争がありますが、絶対にそうではありません。

パブリックインターフェイスに200個のメンバー関数を持つクラスを渡すことができます。これは、最も人間が読み取れるパブリックインターフェイスかもしれません。そのようなコードとそのドキュメントを何気なく読むだけの喜びかもしれません。ただし、読みやすさにもかかわらず、これらすべての機能が相互にどのように相互作用するかを気にしなければならず、誤用に起因するトリッキーなエッジケースに注意する必要があるため、「単純」とは呼びません。

「読みやすさ」は人間のエラーを防ぎ、コードの保守性を改善するという点で私にとって最優先事項ではないため、200に読みにくい20のメンバー関数を持つクラスを好むでしょう。それを変更することができます、すなわち）。

ただし、これはすべて「単純さ」の個人的な定義にかかっています。「可読性」は、典型的には変化しないことを誰かが、彼らは正規表現は私たち単なる人間の残りの部分を忘れて、例えば、非常に「読みやすい」と考えていることはあまり専門知識と流暢さを取得していない限り、私たちの間で乱暴。

シンプルさ

昔、「シンプル」とは「できるだけ読みやすい」ことを意味すると思っていた時代がありました。したがって、構文を改善し、できる限り読みやすく、書きやすいものにするために、多くの便利な関数を使用してCコードを記述します。

結果として、非常に大きく、リッチで高レベルのライブラリを設計し、すべての自然な人間の思考のための関数をモデル化しようとしました。私が当時書いたコードは、最も「読みやすい」かもしれませんが、最も「保守不能」で「複雑」でもありました。

Lisp

それでも、私は90年代半ば（後発）にLISPに短い情熱を抱いていました。「シンプル」という私の考え全体を変えました。

LISPは最も読みやすい言語ではありません。入れ子になった括弧のボートロードで再帰関数を呼び出しながらCDRとCARを抽出することは、非常に「読みやすい」とは誰も考えないことを願っています。

それにもかかわらず、言語の奇妙な構文と完全に再帰的なやり方に頭を悩ませるのに苦労した後、それは私の単純さの考え方を永久に変えました。

LISPで書いたコードで私が見つけたのは、そのように考えることのトリッキーさが私にもっと露骨な間違いを犯させたにもかかわらず、私はもう微妙なエラーを犯していなかったということです（しかし、それらは簡単に見つけて修正できます）。関数が何をしているのかを誤解しておらず、微妙な予期しない副作用を逃していませんでした。私は、一般的に変更を行い、正しいプログラムを作成するのが楽でした。

LISPの後、私にとってのシンプルさは、ミニマリズム、対称性、柔軟性、副作用の減少、無限のさまざまな方法で一緒に組み合わされる柔軟性の少ない機能についてでした。

最も信頼できるコードは存在しないコードであるという考え方に感謝するようになりました。それは大雑把なメトリックにすぎませんが、その量に基づいてコードの信頼性が失われる可能性があると思う傾向があります。構文上の最大限の利便性と読みやすさを追求すると、その量が大幅に増加する傾向があります。

ミニマリズム

LISPの考え方が組み込まれているため、私は最小限のAPIを好むようになりました。「便利な」ヘルパーを大量に提供し、コードを「読みやすく」する可能性があるものよりも、利便性が低く、読みにくい可能性のある、より少ないがより信頼性の高い柔軟な機能を備えたライブラリを好むこれらの数千の機能の1つが何をするのかを誤解することから生じる、信頼性の低い問題や驚きの問題。

安全性

LISPのもう1つのことは安全性です。それは最小限の副作用と純粋な機能を促進し、言語での読み書きの難しさが10秒後に見つけることができる露骨な間違いを増やしたにもかかわらず、私はもはや微妙な間違いを犯すのを見ていませんでした。

純粋な関数と不変の状態は、次の構文であっても、余裕があればいつでも私にとって好ましいものになりました。

sword = sharpen(sword)

...は、以下よりもやや単純で人間の思考から切り離されています。

sharpen(sword)

読みやすさVS。シンプルさ

さらに、LISPは最も「読みやすい」言語ではありません。多くのロジックをコードの小さなセクションに詰め込むことができます（1行に複数の人間の考えがあります）。私は理想的には「読みやすさ」のために1行に1つの人間の考えを好む傾向がありますが、それは必ずしも「単純さ」のためではありません。

このような「シンプル」の定義では、「シンプル」が「読みやすい」と実際に競合する場合があります。これは、インターフェース設計の観点から物事をより考慮しています。

シンプルなインターフェースは、それを使用するために学ぶことをはるかに少なくする必要があることを意味し、潜在的に、そのミニマリズムの結果として、より高い信頼性とより少ない落とし穴があります。主題に関する包括的なドキュメントは、大量の本ではなく小冊子に収まる場合があります。それにも関わらず、それはもっと面倒な作業を必要とし、読みにくいコードを生成するかもしれません。

私にとって「シンプル」は、システムの機能を幅広いレベルで理解する能力を向上させます。私にとって「読みやすい」とは、小さなコードの各行を自然言語と思考に結び付ける能力を向上させ、特に言語に堪能でない場合に、コードの1行が何をするかについての理解をスピードアップする可能性があります。

正規表現は、私が「非常に単純」と考えるものの例です。私の個人的な好みには「単純すぎて読みにくい」です。これらの両極端の間にはバランスのとれた行為がありますが、正規表現には、定義どおりのLISPのような単純さの品質があります。ミニマリズム、対称性、信じられないほどの柔軟性、信頼性などです。流readableになるとは思わないほど読めなくなってしまいました（私の脳はうまく動かないので、正規表現コードを流writeに書ける人がうらやましいです）。

とにかく、それは「シンプルさ」の私の定義であり、「読みやすさ」とは完全に独立しており、時には他のものと干渉することさえあり、より「構文的に便利」で読みやすいがより大きなライブラリまたは「構文的に「不便」、読みにくい、さらに小さいライブラリ。私はいつも、読みやすさとより自然な人間のシンタックス（正規表現の点ではない）を多少犠牲にして、ミニマリズムへの強い選好で、後者に合わせて真の「理解の利便性」と真の「維持可能性」優先順位を見つけました。YMMV。

常に？- はい

適切なレベルの単純さを達成することは、複雑で困難な取り組みです。しかし、常に読みやすさが向上するため、常に価値があります。キーは深い理解であると思います。シンプルさは絶対的なものであり、コードの「チャンク」ごとに「新しい概念」によって測定されます。いくつかの新しい概念は、よりシンプルであることを意味します。

概念が密集している領域に焦点を当て、「チャンク」、「要約」、または「抽象化」する方法を見つけます。コードを数回パスして、コードをよりシンプルで読みやすくします。

優れた抽象化は、金の重さの価値があります。優れた抽象化により、これがより簡単になり、結果として読みやすくなります。

質問は、スタックオーバーフローに関するこの答え、特にこの引用（シンプルで質の高いもの）を思い出させます。

品質-それが何であるかは知っていますが、それが何であるかはわかりません。しかし、それは自己矛盾しています。しかし、いくつかのものは他のものよりも優れています。つまり、品質が向上しています。しかし、品質が何であるかは別として、品質が何であるかを言おうとすると、すべてが馬鹿になります！話すことは何もありません。しかし、品質とは言えない場合、それが何であるかをどのように知っていますか？誰もそれが何であるかを知らない場合、すべての実用的な目的のために、それはまったく存在しません。しかし、すべての実用的な目的のために、それは本当に存在します。グレードは他に何に基づいていますか？なぜ他の人は、あるものに金を払って、他の物をゴミの山に投げ入れるのでしょうか？明らかに、いくつかのものは他のものよりも優れていますが、「ベターネス」とは何ですか？-くるくると、メンタルホイールを回転させ、どこにもトラクションを得る場所を見つけられない。品質とは何ですか？それは何ですか？

コード化されたコーディング標準がすべての利点を備えているからといって、良いプログラマーが悪いプログラマーから抜け出すことはできないということを覚えておくことは重要だと思います。「シンプル」などの単語は、人によって解釈が異なる場合がありますが（エイダンカリーの答えを参照）、それはそれほど悪いことではないかもしれません。ジュニアプログラマーは、シニアプログラマーにコードをレビューしてもらい、シニアプログラマーが「シンプル」の解釈が自分よりも優れている理由を学ぶ必要があります。

1行に1つの関数呼び出しが簡単ですか？例を試してみましょう！

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

どう思いますか？行ごとに1つの呼び出しが実際に簡単ですか？