可読性、理解容易性、正しさへの迷いは作業者のバックグラウンドに依存する
コンピュータ・プログラミングにおける可読性（readability）とは、プログラムのソースコードを人間が読んだときの、その目的や処理の流れの理解しやすさを指している
ソースコードを保守するのは人間であるため、その可読性は重要である（ただし、未熟なプログラマが、よく使われるイディオムによる簡潔なコードを「可読性の低いコード」と見なしてしまうことがあり、読む人間のスキルもまた重要である）
コーディングスタイルの規則の大部分はコードの意味には何ら関係なく、主に可読性に関するものである。例えば以下のようなものである。
字下げスタイルの違い
コメント
問題の分割の仕方
各種オブジェクトの命名規則（変数名、クラス名、手続き名など）
@mizchi: 極端な話、 for 文より再帰ループのが読みやすいと評価する人もいるので .... @mizchi: 競プロに慣れた人は競プロのショートコーディングを一種の慣習として読みやすいと感じることもありえるわけで、そこでチームワークのための可読性って言葉を使うのは主観の押しつけ後出しじゃんけんだと思いました @mizchi: あと細かい話だけどライブラリ書いてるとき、それをアプリケーションに組み込んでるとき、業務コード書いてるとき、OSS書いてるときで良いコードの指標は違うよね @mizchi: なんでこの記事に噛み付いてるかと言うと、今まで一つのコーディングスタイルしか知らない人が、別のベストプラクティスに対して普通はこうでしょって主観を押し付けるのを何度か見てるからです よくわかるkoushisa.icon
だから可読性をプログラムの評価指標に使うのは難しい
何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。
ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。
よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現されるわけです。 ~
というわけで、「わかりやすさ」の主張には慎重になってほしい、という話でした。
@sugimoto_kei: プログラミング界隈は、コードの「読みやすさ」というものにこだわり過ぎだと思う。読みやすさは読み手の経験や知識に大きく依存する。僕の読みやすさとあなたの読みやすさは違う。むしろ、コードが場当たりではなく明確なモデルに基づいているか、関心が分離されているかといったことを問うべきだ。