話をし、理由を付けて、美しいコードについて多くのことを議論するのが慣習ですが、それでも、「美しい」コードとは何か、それがどうあるべきかはまだ明確ではありません。 「コードの美しさ」を決定する複雑さは驚くことではありません。誰もがプログラムの世界だけでなく、人々の世界でも「美しさ」の概念を持っているからです。 しかし、ほとんどの人が同意する美しさの特定の一般的な基準があります。 それらを定式化することは困難ですが、無意識のうちに誰もがこれが美しいことを理解しており、これは非常にそうではありません。
それほど前ではないが、非常に興味深いアンケートが公開され、彼らの経験によると、美しいコードに関する開発者の意見が共有されました。 私の意見では、非常に興味深い研究が得られました。 それについてもう少し広く考えてみましょう。
現在、多くの方法論情報が利用可能であり、さまざまな学校、傾向、そして「美しいコード」を書くための正式な技術さえも形成されつつあります。 この点に関して、若いプログラマーが方法論に従うことに熱心であることに気付かないことは困難であり、「このコードの一部を他のイデオロギーの「禅」と見なすかどうか」などの一見重要ではないことについて議論します。 そして、あなたが数えるなら、それはどれほどイデオロギー的にきれいですか？
一方、より成熟した（したがって、冷笑的で実用的な）開発者は、イデオロギーへの熱意がしばしば幼稚であることを知っています。 そして最後に、非常にベテランの達人は、美しいコードのすべての慣行を「コードを書いて、やりなさい！」というマントラに還元することができます。 これで十分だと思われます。 彼らは素晴らしい経験とコーンに満ちているという理由だけで、自分で美しいコードを手に入れたことに単に気づきません。 それでも、美しいコードとは何ですか？
調査に答えて、8歳の開発経験を評価し、適切なグループで回答しました。 私の答えが私の「年齢」グループで最も人気のあるものとほぼ完全に一致したことに、私は非常に驚きました。 だから、私の仲間は私の志を同じくする人々です！ これはすごい！
「美しいコード」が何であるかについて頭に直接尋ねられていたなら、おそらくキャプテンのスタイルで、いくつかの一般的なフレーズで答えていただろう。 私にとって、コードの「美しさ」は、おそらくその優雅さ、不必要な複雑さの欠如、単一のアイデアの存在などによって決定されます。 常にこのようなコードを書くことができれば...現実の世界では、完全に美しいコードは球形で、真空でしか見ることができません。
私たちがどれほど独創的で理想主義的であっても、私たちは期限内に働きます。 たとえそれがオープンで非営利的なプロジェクトでの作業であっても、とにかくすべての経験、知識、魂を注ぎ込んだとしても、とにかく、リリースしたいという欲求は、最終的に、遅かれ早かれ世界に私たちの仕事の結果をもたらします。 また、期限があるため（コードが作成者を離れなければならない特定の境界）、時間通りに作業を完了するために妥協する必要があります。 好むと好まざるとにかかわらず、私たちの仕事は複雑です。 エレガントなアーキテクチャとソリューションが常に頭を悩ますわけではありません。 これは、松葉杖、プラグ、ハードコード、およびその他の「小さなトリック」が生まれる方法です。
「私が望んだ方法」と「それがどうなったか」の違いは、スペシャリストとしての人が小さければ小さいほど良いことです。 差が非常に小さい場合、そのようなコードは通常美しいです。
それでは、前述の美しいコードの投票で出された質問に戻りましょう。
美しいコードを書く必要があります...可能であれば。
そうです、「可能な限り」。 私たちは皆、彼らの恵みに魅力的な素晴らしいプログラムを書きたいと思っています。 くだらないものを作りたい人を見せてください。 これを心から望んでいる人はいないと思います。 問題は、常にうまくいくとは限らないことです。 締め切りは厳しく、ミューズの不足、知識は厳しくなっています。 experiencedいソリューションを実行する経験豊富なプログラマーは、将来それを削除する方法を考えます。 彼は、何が許される悪で、何が完全に汚れであるかを確実に知っています。
経験の浅いプログラマーも汚くなりたくありませんが、「悪の許容性」の基準ははるかに低いことがよくあります。 すべての変数に1文字の名前を付け、それらをすべてグローバルスコープに配置し、コードをインデントしないでください。 同じように機能します。
可能であれば、そのようなコードを記述しないことをお勧めします。 可能性（経験）がない場合は、まだ書く必要があります。 ウォーキングは道路を圧倒します。タスクを解決する必要があります。
美しいコードは...
ここでは、すでにより興味深いものになっています。 コードに固有の美しさの基準は何ですか？
「カーソルがどこに行くのか、そこに書く」という原則に従ってインデントが行われるコードを見てください。変数には意味のない名前が付けられ、ロジックはコード全体に広がり、ユーザーの操作はデータベースコードと混合されます。 「コードはひどい」としっかりと言うために必要なのは、ほんの一瞬だけです。 これは、非常に初心者のアマチュアのコードです。 各サイクルがあなたにとって「脳テスト」であったときに、あなたはこれらすべてを書いたと思います。 これは経験に基づいていますが、このようなコードには美しさがあり得ないことは明らかです。
私の意見では、自然言語のテキストのように、美しいコードは理解できるはずです。 「覚えやすい」とある答えを読んでください。 これが主な基準だと思います。 統一されたデザインスタイルの要件は、ニーモニックな理解を確保する手段の1つです。 単一のスタイルを使用すると、理解が容易になります。 美しいコードは同じスタイルでなければなりません。 どちらでもかまいませんが、1つです。 たとえば、アンダースコアで始まるクラスのメンバー変数に名前を付ける最も簡単な規則は、読みやすさを大幅に向上させます。 小さな下線は、コード内で「ローカル」メソッドデータとクラス全体が依存するデータを明確に強調しています。 別の例は、ゲッター/セッターメソッドの統一された命名スタイルです。 それらがすべて何らかの接頭辞で始まるが、脳がこれらの方法が何であるか、なぜそれらが必要なのかを即座に理解する場合。 追加の説明を得るために、メインの読書から注意をそらし、コード内の別の場所に登る必要はありません。
2番目の非常に重要な基準は、コードの安定性です。 原則として、テストが提供されます。 安定したコードは見た目も美しくありません。 彼は彼のパフォーマンスの均一性でハンサムです。 新しいデータが設計されていないコードに送信された場合、信頼できると思われるコードが突然正しく実行されると、本当に嬉しいです。 私はそのようなコードを喜んでおり、それを賞賛さえします（もちろん、自分自身、自分自身、なぜ分散するのか）。 優れたアスリートやミュージシャンがハンサムであるように、安定したコードは美しいです。 彼はできます、悪魔！
そして最後の重要な基準は、拡張の容易さです。 ここで、多くの話はうまくいきません。 彼らが言うように、船の設計者がボートを作り、エンジンを掛け、1000人の乗客を収容し、チーム、300のボート、対空砲を数えない場合、彼は「私はあなたにはプログラマーではありません！」 私たちの仕事に永続的なのは変化だけです。 それらを予測する能力は才能です。 拡張ポイントがメインタスクに適切に含まれるコードを熟考するとき、「美しい！」と言います。
私の意見では、これらはコードの「美しさ」の唯一の必須基準です。 コメントもボリュームもパフォーマンスも、コードを「美しく」しません。 美しくて抑制的なコードは、まだ美しいとは言えません。 コードを見るときれいですが、開始すると吐き出します。 おそらく、これは美しいが、愚かで空っぽの男のようなものです。
美しいコードは...
ああ、それはここで一般的に楽しいです。 理想について話すのは良いことです。他の人に教えるのは良いことです...しかし、私たちは皆罪人です。 オプションを作る代わりに、誰も難しい意味を定めたことはありません-最初に彼に石を投げさせてください。 「美しいコード」の罪について話しましょう。
もちろん、美しいコードにはコメントがまったく含まれていない場合があります。 コメントを持つことは、まったく別のホリバーです。 コメントを整理してみましょう。 コメントに対する主な非難は、彼らが嘘をついているということです。 2番目の非難-彼らは明白なことを説明し、非常にまれに-本当に説明が必要です。
賢い人の一人は、次のように言った。 コメントは、彼がそれを行う理由を示す必要があります。」 議論するのが難しい黄金の言葉。 「何？」という質問は、コード自体に完全に答えます。 コードに複雑な構造や不明瞭な構造が表示されている場合、それがここにある理由を理解することが重要です。 削除または変更するとどうなりますか？ そのような構造の隣にコメントがある場合、「変数Aを値Bに割り当てる」というスタイルになります。 「助けてくれてありがとう！」-あなたは誓い、分析を始めます。
なぜこれが起こっているのですか？ 私の意見では、答えは明らかです。 プログラマーは純粋な思考で作業します。 タスクに没頭するときは、非常に集中する必要があります。 コードを詰め込むプログラマーの頭の中には、メンタルな構成による脆弱なロックが組み込まれています。 少し注意をそらす価値があり、すべてが崩壊します。 さて、そのような状況でコメントすることで誰が気を散らすのでしょうか？ 著者の意識の流れが言及された種類のコメントを引き起こすことがある場合、これは執筆時点で彼が正確にこのレベルの詳細で作業していたためです。
ほとんどの場合、この「A = B」の割り当ては本当に重要であり、著者がマークする必要があると考えるアルゴリズムの重要なポイントです。 彼は「なぜ」とは書いていませんでしたが、その瞬間に彼はそれを明白だと考えたので、この割り当てをしなければなりません。 このコメントに「メソッドの結果....」を追加するだけで、コメントがより明確になります。 問題は、深い没入時に、クリスタルキャッスルを破壊せずに、作者が最大のディテールのレベルから抜け出せなかったことです。 解説は非常に明確ですが、読者がアルゴリズムに没頭していない場合は役に立ちません。
コードが作成されると、時々「コーム」され、その後コメントが書き直されて洗練されます。 そして、もう一つの待ち伏せがあります-コメントは遅かれ早かれ廃止され、コードは書き直され、彼らはそれを忘れます。
したがって、「コメントを削除し、自己文書化コードを書く」という要件は非常に公平です。 しかし、自己文書化コードがどれほど優れていても、「何」を完全に説明しますが、「なぜ」という質問にはほとんど答えられません。 美しいコードにはコメントが含まれていない場合がありますが、コメントがあり、特定のフラグメントが記述されている理由を説明すると、コードがさらに美しくなります。
私に受け入れられると思われる次の「罪」は、コードのサイズです。 美しいコードは大きすぎる場合があります。 多くの場合、拡張可能な機能の要件が定義されていない場合、サイズは拡張性を達成しようとします。 その場合、拡張ポイントの思慮深い埋め込み、単純なタスクに対するアーキテクチャの外観により、コードはさらに美しくなります。 「別の対空砲を吊るす」という要件への恐怖は、オーバーエンジニアリングのモンスターを作ることを余儀なくさせます。
簡単な要約
記事はありませんが、私たちはそれぞれ、美しいコードが何であるかを理解しています。 美しさには正式な基準はありませんが、非常に明確に感じられます。 美しいコードとは、すぐにすべてを選択して「削除」をクリックしたくないというコードです。 美しいコードに関する調査に参加したすべての「世代」の驚くべき一致は、これを裏付けています。
PS
これはHabrの最初の記事です。 私はあなたがここでどれほど厳しく厳しいかを知っているので、何かがあなたにとって露骨なゴミのように見えるなら、私はあなたに懇願します。そして、怠tooになりすぎないでください。
ご清聴ありがとうございました。