優れたプログラマーのコードはどのように見えますか？
私は趣味のプログラマーであり（Excelを高速化するためにVBAから始めました）、VB.NET/C＃.NETで作業しており、ADO.NETを学ぼうとしています。
私をいつもイライラさせていたプログラミングの側面は、「良い」とはどういうものかということです。私はプロではないので、比較することはほとんどありません。優れたプログラマーとは何ですか？それは...ですか：
- 特定の言語のすべてのオブジェクト/クラス/メソッドをよりよく理解していますか？
- 彼らのプログラムはより効率的ですか？
- プログラムの設計は、ドキュメントの改善、関数名の適切な選択などの点ではるかに優れていますか？
別の言い方をすれば、プロのプログラマーのコードを見た場合、自分のコードと比較して最初に気付くのは何ですか？たとえば、Wrox pressの「Professional ASP.NET」のような本を読んでいます。その本のコード例は「世界クラス」ですか？それは頂点ですか？一流のプログラマーはそのコードを見て、良いコードだと思いますか？
以下のリストは包括的なものではありませんが、これらはあなたの質問を検討する上で私が考えたことです。
良いコードはよく組織されています。クラスのデータと操作は一致します。クラス間に無関係な依存関係はありません。 「スパゲッティ」のようには見えません。
良いコードのコメントは、物事が行われているのではなく、なぜ行われているのかを説明しています。コード自体が実行内容を説明しています。コメントの必要性は最小限に抑える必要があります。
優れたコードは、最も一時的なオブジェクトを除くすべてのオブジェクトに対して意味のある命名規則を使用します。何かの名前は、オブジェクトをいつどのように使用するかについての情報です。
良いコードは十分にテストされています。テストは、コードとその使用例の実行可能な仕様として機能します。
良いコードは「賢い」ものではありません。それは単純明快な方法で物事を行います。
優れたコードは、小さくて読みやすい計算単位で開発されます。これらのユニットはコード全体で再利用されます。
まだ読んでいませんが、このトピックで読む予定の本は、ロバートC.マーティンによる Clean Code です。
最初に気付くのは、コードが一貫した coding-style に従っていることです。彼らは常に構造ブロックを同じように書き、宗教的にインデントし、必要に応じてコメントします。
2番目に気付くのは、コードがせいぜい数十行の小さなメソッド/関数に分割されていることです。また、自己記述型のメソッド名を使用し、一般にコードは非常に読みやすくなっています。
コードに少し手を加えた後、3つ目に気付くのは、ロジックをたどりやすく、変更しやすく、したがってメンテナンスが容易であることです。
その後、ソフトウェア設計技術に関する知識と経験が必要になり、コードアーキテクチャを構築する際の具体的な選択を理解する必要があります。
本に関しては、コードが「ワールドクラス」と見なされる本はあまり見ていません。本では、彼らは主に単純な例を提示しようとしています。これは非常に単純な問題の解決に関連する可能性がありますが、より複雑な状況を反映していません。
ファウラーの引用、読みやすさの要約：
愚か者はコンピューターが理解できるコードを書くことができます。
優れたプログラマーは、人間が理解できるコードを作成します。
」と言った。
個人的には、ティムピーターズによる "The Zen of Python"を引用する必要があります。 Pythonプログラマーにコードがどのように見えるかを伝えますが、基本的にすべてのコードに適用されることがわかります。
いよりも美しいほうがいい。
明示的は暗黙的よりも優れています。
単純なものは複雑なものよりも優れています。
複雑さは複雑さよりも優れています。
Flatはネストよりも優れています。
スパースは、デンスよりも優れています。
読みやすさは重要です。
特別なケースは、ルールを破るほど特別ではありません。
実用性は純度よりも優れていますが。
エラーが静かに渡されることはありません。
明示的に沈黙しない限り。
あいまいさに直面して、推測する誘惑を拒否します。
それを行うための明白な方法は、1つでなければなりません。
オランダ人でない限り、その方法は最初は明らかではないかもしれませんが。
今では、これまで以上に優れています。
多くの場合、rightよりも優れていることはほとんどありません。
実装の説明が難しい場合、それは悪い考えです。
実装の説明が簡単な場合は、良いアイデアかもしれません。
名前空間は素晴らしいアイデアの1つです。それらをさらに活用しましょう。
コードは詩です。
ロジックのこのポイントから開始すると、コードの多くの望ましい品質を引き出すことができます。最も重要なことは、コードが書き込まれるよりもはるかに多く読み取られることに注意してください。したがって、リーダー用のコードを記述してください。リーダーの書き換え、名前変更、編集、およびリファクタリング。
当然のフォロー：
読者は、コード作成日からn時の時点であなたになります。読者にコードを書くことの見返りは、nの単調増加関数です。コードを初めて見る読者は、n == infinityで示されます。
言い換えると、コードを書いてからコードを再訪するまでの時間のギャップが大きいほど、読者のために書く努力に感謝します。また、コードを引き渡す人は誰でも、一番の考慮事項としてリーダーで書かれたコードから大きな利益を得るでしょう。
2番目の結果：
読者に配慮せずに記述されたコードは、理解したり使用したりするのが不必要に難しい場合があります。リーダーに対する考慮事項が特定のしきい値を下回ると、リーダーは、コードを書き換えることによって得られる値よりも少ない値をコードから導き出します。これが発生すると、以前のコードは破棄され、悲劇的なことに、書き換え中に多くの作業が繰り返されます。
3番目の結果：
結果2は、文書化が不十分なコードの後に強制的に書き換えられるという悪循環で何度も繰り返されることが知られています。
私は28年間プログラミングを行ってきましたが、これは答えるのが難しい質問です。私にとって、良いコードは完全なパッケージです。コードは、意味のある変数名とメソッド名できれいに書かれています。コードの意図をコメントするコメントが適切に配置されており、既に読んでいるコードを単に逆流するだけではありません。コードは、リソースを浪費することなく、効率的な方法で想定されることを実行します。また、保守性に目を向けて書かなければなりません。
一番下の行は、しかし、それは異なる人々にとって異なることを意味するということです。私が他の誰かが嫌うかもしれない良いコードとしてラベル付けするかもしれないもの。良いコードには、上記で特定した共通の特徴がいくつかあります。
あなたができる最善のことは、自分自身をコードにさらすことです。他の人のコードを見てください。オープンソースプロジェクトはそのための良いソースです。良いコードと悪いコードが見つかります。よく見ると、良いコードと悪いコードであると判断したものをよりよく認識できます。
最終的には、あなた自身の裁判官になります。好きなスタイルやテクニックを見つけたら、時間をかけて自分のスタイルを思いつき、それは時間とともに変化します。ここには杖を振って、何が良いのか、他の何も悪いのは言うことができない人はいません。
コードの完全な本を読んでください。これは、コードの構造化方法とその理由に関する多くのアイデアを説明しています。それを読むことは、良いことと悪いことを区別するのに必要な経験を獲得するための時間を短縮するはずです。
自分で10年近くプログラミングをしていて、他の人と一緒に働いたことがありますが、バイアスなしで言うことができます優れたプログラマーと平均的なプログラマーのコードには違いはありません
有能なレベルのすべてのプログラマー：
- 正しくコメントする
- 効率的な構造
- 文書をきれいに
私はかつて同僚に「私は常に非常に論理的かつ合理的であることに気づきました。だから開発を楽しんでいると思います」
私の意見では、それは平均的なプログラマーの心です。ルールとロジックの観点から世界を見て、最終的にプログラムを設計および作成する際にそれらのルールに従います。
エキスパートプログラマーは、ルールだけでなく、そのコンテキストも理解しています。これは最終的に、専門家プログラマーのマークである新しいアイデアと実装を考え出すことにつながります。 プログラミングは最終的にアート形式です。
- 読みやすい
- 書きやすい
- メンテナンスが簡単
他のすべてはフィリグリーです
簡潔に言えば、優れたプログラマーのコードを読んで理解することができます。
私の意見では、良いプログラマーのコードは言語に依存しない;よく書かれたコードは、使用するプログラミング言語に関係なく、最小限の思考で短時間で読み取り、理解できます。コードがJava、Python、C++、Haskellのいずれであっても、適切に記述されたコードは、その特定の言語でプログラミングさえしていない人でも理解できます。
読みやすいコードの特徴には、名前が付けられたメソッド、「トリック」および複雑な「最適化」の欠如、クラスが適切に設計されていることなどがあります。他の人が述べたように、コーディングスタイルは一貫性があり、簡潔で簡単です。
たとえば、先日、私は TinyMCE のコードを見て、Stack Overflowの質問の1つに答えていました。 JavaScriptで書かれていますが、私はこれまでほとんど使用していませんでした。ただし、コーディングスタイルと含まれているコメント、およびコード自体の構造化により、かなり理解しやすく、数分でコードをナビゲートすることができました。
優れたプログラマーのコードを読むという点で、私にとって非常に目を見張るものだった本は 美しいコード さまざまなプログラミング言語のさまざまなプログラミングプロジェクトの作者によって書かれた多くの記事があります。しかし、それを読んだとき、その特定の言語でプログラミングしたことすらなかったという事実にもかかわらず、著者がコードで書いていることを理解できました。
おそらく私たちが心に留めておくべきことは、プログラミングはコンピューターだけでなく人々とのコミュニケーションでもあるため、優れたプログラマーのコードはほとんどよく書かれた本。読者に伝えたいアイデアを伝えることができます。
良いコードは簡単に理解できるはずです。
十分にコメントする必要があります。
難しい部分にはさらにコメントを付ける必要があります。
良いコードは読みやすいです。優秀なプロのプログラマーによって書かれたコードの最初の読み取りでコードが何をしているのかを理解するのに問題はありません。
むしろ、他のみんなの素晴らしい提案を繰り返して、代わりにあなたが本を読むことをお勧めします Code Complete by Steve McConnell
基本的には、機能とスタイルの両方のプログラミングのベストプラクティスが満載された本です。
あなたのコードにコメントを追加したかっただけです...そして、一般的にはあなたのコード自体があなたのコードが何をするのか、今ではそれがどうなるのかを言うべきです。他のコードを呼び出すコードである「クライアント」コードの概念を取得したら（最も簡単な例はメソッドを呼び出すコードです）、「クライアント」の観点からコードをわかりやすくすることについて常に最も心配する必要があります。コードが大きくなるにつれて、これが...ええと、良いことがわかります。
良いコードに関する他の多くのことは、あなたが作る精神的な飛躍に関するものです（間違いなく、あなたが注意を払えば）...それらの99％は、あなたに多くのことをspareしまないためにもう少し仕事をすることに関係しています後で動作し、再利用可能。また、正しいことをすることで：正規表現を使用するのではなく、ほとんど常に他の方法で実行したいのですが、それらにアクセスするたびに、everybodyが作業するすべての言語でそれらを使用する理由がわかります（それらは難解ですが、動作し、おそらくより良いことはできませんでした）。
本を見るかどうかについては、私の経験では間違いなくと言います。 APIとフレームワーク、コード規約、および他の人のコードを見て、自分の本能を使用し、物事がそうである理由と物事の意味が何であるかを理解しようとします。書籍内のコードがほとんど実行しないことは、計画外の計画です。これがエラーチェックのすべてです。これは、誰かがあなたに電子メールを送信し、「ちょっと、アプリが壊れたよ」という代わりに「エラー321になりました」と言ったときにのみ報われます。
優れたコードは、プログラマーの観点とユーザーの観点の両方から未来を念頭に置いて書かれています。
[純粋に主観的な答え]
私にとって、良いコードとは絵画のような芸術の一形態です。さらに説明すると、実際には、文字、色、コードの「フォーム」または「構造」を含む図面であり、これらすべてが非常に読みやすい/パフォーマンスが高いと言えます。読みやすさ、構造（列、インデント、同じ長さの変数名でさえも！）、色（クラス名、変数名、コメントなど）の組み合わせはすべて、「美しい」画像として見たいものを作ります。自分のコードを非常に誇りに思うか、非常に嫌悪感を抱かせてください。
（前述のように、非常に主観的な答え。私の英語で申し訳ありません。）
私は、ボブ・マーティンの「クリーンコード」の推奨を2番目に推奨します。
「美しいコード」は数年前に高く評価されました。
McConnellの本はどれも読む価値があります。
おそらく、「実用的なプログラマー」も役立つでしょう。
％
次に、ボブおじさんの「クリーンコード」の推奨事項。しかし、あなたは http://www.Amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 を見てみたいと思うかもしれません少し良く。良いコードはページから飛び出し、何をするのか/どのように動作するのかを伝える必要があります。
Jeff Atwoodは、コーダーがタイピストの最初のリファレンスである方法についての素敵な記事を書きました： http://www.codinghorror.com/blog/archives/001188.html
タイピストであるとき、あなたは常にあなたの仕事でエレガントである必要があります、構造と適切な「文法」を持つことは非常に重要です。これを「プログラミング」に変換すると、同じ結果が得られます。
構造
コメント
地域
私はソフトウェアエンジニアです。つまり、教育中に多くの異なる言語に出くわしましたが、私のプログラミングはfekberg.wordpress.comで行っているように、「特殊な」タイピングの方法があるので、プログラミングは常に同じように感じます。
Java、C＃、アセンブラー、C++、Cなど、さまざまなアプリケーションとさまざまな言語でプログラミングするようになりました。
私はすべてを「ボックス」またはリージョンと見なし、各リージョンにはコメントの説明があります。領域は「クラスPerson」であり、この領域内にはプロパティのメソッドがいくつかあります。これらのメソッドは「アクセスメソッド」などと呼ばれ、各プロパティと領域には独自の説明コメントがあります。
これは非常に重要です。API構造を作成するときに「apiの一部である」ことを示すコードを常に表示し、エレガンスは[〜＃〜] very [〜＃ 〜]重要です。
これについて考えます。また、Communication issues when adapting outsourcingに関する私の論文も読んでください。これは、大まかに、悪いコードがどのように競合する可能性があるかを説明しています。あなたの好きなようにEnterpret： アウトソーシングの適応時の問題/
これは、ファウラーの本「リファクタリング」でかなりよく回答されています。それは、彼が本全体で説明しているすべての「匂い」がないことです。
「Professional ASP.NET」は見たことがありませんが、それが「OK」よりも優れている場合は驚かれることでしょう。本当に良いコードの本については この質問 をご覧ください。 （もちろん変わりますが、受け入れられている答えは打ち負かすのが難しいです。）
これはFAQであるようです（そうあるべきです）。最近、美しいコードについて ACMの記事 があります。読みやすい/理解することに重点が置かれているようです。私はこれを「ドメインの専門家が読みやすく、理解しやすい」と評価します。本当に優れたプログラマーは、与えられた問題に対して、わかりやすいO（n ^ 2）アルゴリズムではなく、最良のアルゴリズムを使用する傾向があります。プログラマーがアルゴリズムへの参照を提供します。
優秀なプログラマーを含めて完璧な人はいませんが、彼らのコードはstriveの傾向があります：
- 実績のあるアルゴリズムを使用した正確性と効率性（単純なアドホックハックの代わりに）
- 明快さ（非自明なアルゴリズムを参照した意図に対するコメント）
- 基本（コーディング規則、バージョン管理、ドキュメント、単体テストなど）を網羅する完全性
- 簡潔さ（乾燥）
- 堅牢性（任意の入力に対する耐性と変更要求の中断）
優れたコードは、理解しやすく、保守しやすく、追加しやすいです。理想的には、他の指標を犠牲にすることなく、可能な限り効率的でもあります。
私にとって素晴らしいコードは、シンプルでありながら洗練されたものです。 「もちろん、どうしてそんな風に考えなかったの？」本当に良いコードを理解するのは難しくありません。単純な方法で（または、より単純な場合は再帰的な方法で）手元の問題を解決するだけです。
良いコードは、メソッドが名前から何をするかを知っている場所です。悪いコードは、名前の意味を理解するために、コードが何をするかを解決する必要がある場所です。
良いコードは、それを読むと、読むのに必要な時間よりも長くはかからずに、何をしているのかを理解できる場所です。悪いコードは、それがするwtfを解決しようとする年齢のためにあなたがそれを見ることになる場所です。
良いコードには、些細なコメントを不要にするような名前が付けられています。
良いコードは短い傾向があります。
良いコードは、目的とはまったく関係のないものに依存していないため、他の場所で行うことを行うために再利用できます。
通常、優れたコードは、単純なジョブを実行するための単純なツールのセットです（より洗練されたジョブを実行するために、適切に編成された方法でまとめる）。悪いコードは、壊れやすく使いにくい巨大な多目的ツールになる傾向があります。
コードは、プログラマーのスキルと考え方を反映しています。優れたプログラマーは常に未来に目を向けています-要件や状況が今日のように正確ではない場合にコードがどのように機能するか。それはどのようにスカラバレになりますか？私がこのコードを保守しているのではない場合、どれほど便利でしょうか？コードがどれだけ再利用可能になるか。同様のことをしている他の誰かがコードを再利用でき、再度書くことはできません。誰かが私が書いたコードを理解しようとしているときはどうでしょう。
プログラマーがその考え方を持っているとき、他のすべてのものはうまく配置されます。
注：コードベースは、多くのプログラマーによって長期にわたって取り組んでおり、通常、プログラマーに対するコードベースの特定の指定はありません。したがって、優れたコードは、会社のすべての標準と従業員の質を反映しています。
（これは私が熱望するになる人であるため、以下で「彼」を使用します。
優れたプログラマーの哲学の核心は、彼が常に考えていることだと思います。コードが機能するはずでした。」
そのため、彼のコードは次のことをしなければなりません。
- 作業（コードが間違った答えにどれだけ早く到達するかは関係ありません。現実の世界では部分的な信用はありません）。
- このコードが機能することを彼がどのように知っているかを説明してください。これは、ドキュメント（javadocが私の選択のツールです）、例外処理、およびテストコードの組み合わせです。非常に現実的な意味では、「このコードが機能する、これがどのように使用されるべきであるか、そしてこれが私が得るべき理由である」支払った。」
- 維持されます。デッドコードは悪夢です。レガシーコードのメンテナンスは面倒ですが、やらなければなりません（そして、それはあなたの机を出る瞬間に「レガシー」であることを忘れないでください）。
一方、優秀なプログラマーはこれらのことを絶対にすべきではないと考えています。
- 書式設定にこだわります。あなたが適切であると感じる標準的または個人的な好みに正確にコードをフォーマットできるIDE、エディタ、プリティプリンタがたくさんあります。私はNetbeansを使用し、フォーマットオプションを一度設定して、時々alt-shift-Fを押します。コードをどのように表示するかを決定し、環境を設定し、ツールにうなり声を出させます。
- 人間のコミュニケーションを犠牲にして、命名規則に固執します。命名規則により、「Zookeeper」ではなく「IElephantProviderSupportAbstractManagerSupport」という名前のクラスを作成する場合は、次の人のために標準を変更してください。
- 彼が実際の人間とチームとして働くことを忘れてください。
- コーディングエラーの主な原因は、現在彼のキーボードに座っていることを忘れてください。間違いや誤りがある場合は、まず自分に目を向けるべきです。
- 周りに何が起こるか忘れてください。コードを将来の読者がアクセスしやすくするために彼が現在行っている作業は、ほぼ確実に直接彼に利益をもたらします（誰が彼のコードを見るように頼まれますか？）。
- 最良のコードには特定の優雅さがあり、すぐに認識されます。
- それは細心の注意と細部への注意を払って細工されたように見えます。それは明らかにスキルのある人と制作されており、それについての芸術を持っています-あなたはそれが荒くて準備ができているのではなく、彫刻されて洗練されたように見えると言うことができます。
- 一貫性があり、読みやすくなっています。
- それは小さな、非常に凝集した関数に分割されており、それぞれが1つのことを行い、うまく機能します。
- これは最小限の結合であり、通常、依存関係はほとんどなく、厳密に制御されます...
- 関数とクラスは、実装ではなくabstractionsに依存しています。
私には良い例があります：
GWT（google web takeit）のソースコードを読むと、すべてのバカがそれを理解していることがわかります（英語の本の中にはこのコードより読みにくいものがあります）。
C++コードを作成する場合、uniで参照している優れたコーディング標準を備えた非常に優れた本があります。C++コーディング標準：101のルール、ガイドライン、およびベストプラクティス"ハーブサッター、アンドレイアレクサンドレスク、ビャルネシュトルストラップ。
皮肉なことに、プログラマーの方が良いあまり必要ではない彼/彼女は、生成されたコードが誰よりも保守しやすいためになります（Eran Galperinの一般的な同意によると）。
私の経験では、逆もまた真であることがわかります。 プログラマの方が悪い保守が難しい彼/彼女のコードはそうですより不可欠彼/彼女は、他の魂が理解できないのでなぞなぞが生み出された。
- できます
- 動作することを証明する単体テストがあります
残りはアイシングです...