で、この質問、私はあなたが良いコードを書くことから悪いライター妨げているかどうかを尋ねました。答えの多くは「良いコードの意味に依存します」で始まりました。
「良いコード」と「悪いコード」という用語は非常に主観的なもののようです。私は一つの見方をしているので、他人の見方とは非常に異なるかもしれません。
「良いコード」を書くとはどういう意味ですか？「良いコード」とは何ですか？
回答:
優れたコーダーは、優れたプールプレーヤーのようなものです。
プロのプールプレーヤーを見ると、最初は感心しないかもしれません。「確かに、彼らはすべてのボールを入れましたが、簡単なショットしかありませんでした！」これは、プールプレーヤーがショットを行うときに、どのボールがどのポケットに入るかを考えず、キューボールがどこに到達するかを考えているためです。次のショットを準備するには、ものすごいスキルと練習が必要ですが、簡単に見えることも意味します。
さて、このメタファーをコードに持ち込むことで、優れたコーダーは、簡単でわかりやすいコードを記述します。ブライアン・カーニガンの著書の多くの例は、このパターンに従っています。「トリック」の一部は、問題とその解決策を適切に概念化することです。問題を十分に理解していないと、ソリューションが複雑になりやすくなり、アイデアを統一することができなくなります。
問題を適切に概念化すると、読みやすさ、保守性、効率性、正確性など、他のすべてが得られます。解決策は非常に簡単に見えるため、追加の説明は不要であるため、コメントが少なくなる可能性があります。優れたコーダーは、製品の長期ビジョンを確認し、それに応じて概念化することもできます。
（オリジナル）
編集：基本的な考え方は、「コード品質」をルールに入れることはできないということです。同じ方法で、「グッドアート」や「グッドポエトリー」をルールに入れることはできません。または「いいえ、悪い詩」。現在、唯一の方法は、コードが他の人間にとってどれだけ簡単に理解できるかを確認することです。
コードを理解できる速さ以外に、本当に良い基準はありません。簡潔さと読みやすさの完璧な妥協点を見つけることで、コードの見栄えを良くします。
「WTF's per minute」（上記）は正しいですが、それは単なるより一般的なルールの結果です。WTFが多いほど、理解が遅くなります。
RemoveCustomerメソッドは実際にめちゃくちゃにすることなくcutomerを削除すること。見た目を美しくするために何時間も費やすことができますが、実際に機能するという意味ではありません。私が言っているのは、「コードをどれだけ速く理解できるか」だけではありません。
良いコードを書くのは次の場合です...
コードが良いかどうかをどのように測定しますか...
適切なコードは、想定どおりに機能します。良いコードは、必要なときに簡単に変更できます。良いコードを再利用して利益を上げることができます。
あるコード
バグフリー
再利用可能
独立した
それほど複雑ではない
よく文書化されている
簡単に変更できます
良いコードと呼ばれます。
優れたプログラムは問題なく機能し、バグはありません。しかし、どのような内部品質がそのような完璧さを生み出しますか？それは謎ではありません、私たちは時々いくつかの思い出させる必要があります。C / C ++、C＃、Java、Basic、Perl、COBOL、またはASMのいずれのコードを作成しても、優れたプログラミングはすべて同じ昔からの品質を示します：シンプルさ、読みやすさ、モジュール性、階層化、設計、効率、エレガンス、明快さ効率、エレガンス、そして明快
ソース：MSDN
これはおなじみですか？
フィリップスは私に新製品のデザインを見る機会を与えてくれました。それが発展するにつれて、私はますます不安になり、私の懸念を監督者に打ち明け始めました。私は彼に、デザインは「きれい」ではなく、ダイクストラのデザインが美しいように「美しく」あるべきだと言った。彼はこれが有用なコメントであるとは思わなかった。彼は私たちがアーティストではなくエンジニアであることを思い出しました。彼の心の中で私は単に自分の好みを表現していたので、彼は私が判断を下すのにどの基準を使っていたかを知りたいと思っていました。私は彼に話すことができませんでした！違反している原則を説明できなかったため、私のコメントは単に無視され、作業は続行されました。私の「味」を説明し、動機付けを提供する方法がなければならないと感じ、私は、良いデザインと悪いデザインを区別する原理を見つけようとし始めました。エンジニアは非常に実用的です。彼らは美しさを賞賛するかもしれませんが、実用性を求めています。「美」が役立つ理由の説明を見つけようとしました。
ここで残りを見てください。
自然なコード品質基準（最小限のコピー/貼り付け、スパゲッティなしなど）を除いて、優れた産業用コードは、常に少し素朴で、少し冗長すぎて、
int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;
とは対照的に
Record r = cache.get(i++, false);
do_not_create = false、「引数falseとして渡されてdo_not_create作成される」または「引数falseとして渡されて作成されない」という意味do_createですか？引数名を使用できる言語では、私は好むでしょうcache.get (key:i, create: false); i += 1;。
良いコードは人によって異なり、彼らが使用している言語も良いコードとみなされるものに影響を与えます。一般的に、プロジェクトに近づくと、次のことを探します。
これらすべてを超えて、アプリケーションの設計は全体として理にかなっていますか？アプリケーションに常駐するコードは世界で最高のものになる可能性がありますが、アプリケーションの全体的な設計が意味をなさない場合、作業するのは依然として苦痛かもしれません。
読みやすさについて、私は親切に反対させてください。いいえ、完全ではありません：良いコードは読みやすいはずであり、十分なコメントで簡単に達成できます。
しかし、私は2種類のWTFを検討します。プログラマーがプログラミング101よりもさらに進歩したかどうか疑問に思うものと、コードの優しさを絶対に把握していないものです。最初は非常に奇妙に見えるコードもありますが、実際には難しい問題に対する非常に独創的なソリューションです。2番目のものは、WTFメーターには含まれません。コメントで回避できます。
非常に読みやすいコードは、非常に遅くなります。読みにくいソリューションでは、速度が大幅に向上します。Rは、それがよく当てはまる言語の優れた例です。可能な限りforループを避けるのが好きです。一般的に、読みやすさは劣りますが、最速のコードはより良いコードだと思います。つまり、改善が大幅に改善され、コードの機能を説明するために十分なコメントが挿入される場合です。
さらに、多くの科学アプリケーションではメモリ管理が重要になる場合があります。非常に読みやすいコードは、メモリ使用量が少しずさんな傾向があります：作成されるオブジェクトはさらに多くあります。かなりの場合、メモリを賢く使用するとコードが読みにくくなります。しかし、たとえばギガバイトのDNAシーケンスをジャグリングする場合、メモリは重要な要素です。繰り返しになりますが、可読性に関係なく、メモリ集約度の低いコードは優れたコードであると考えています。
そのため、良いコードには読みやすさが重要です。私はUwe Liggisの宣伝を知っています。思考の痛みとコンピューターは安いです。しかし、私の分野（統計ゲノミクス）では、1週間の計算時間と40 Gbを超えるメモリ使用量は異常とは見なされません。したがって、2倍の速度と半分のメモリの改善は、余分な可読性よりもはるかに価値があります。
私にとっては...別のプロジェクトで仕事をしている同僚がやって来て、コードの各ブロックを調べなくても自分がやっていることを理解できるようになったとき、私は良いコードを書いていることを知っています。そしてそれが何をしているかを示す。
彼が「ちょっと待って、何を！？」と言う代わりに。彼は言っています、「ああ、わかりました、あなたがそこで何をしたかわかります。」
また、優れたコードには、巧妙な回避策や「ハッキング」はあまりありません。あなたがそれを書いている間、あなたは自分自身にも言っているとき、「私はこれがそれをする良い方法ではないことを知っていますが、私は今のところこの方法でそれをしなければならないつもりです。私は思い出します後で改善するために自分自身...」
