数学的な証明を書くときの目標の 1 つは、証明を圧縮し続けることです。証明はより洗練されますが、必ずしもより読みやすくなるわけではありません。圧縮は、不要な文字や冗長性を取り除くため、理解を深めることにつながります。
コードフットプリントをできるだけ小さくすべきだという開発者の声をよく耳にします。これにより、判読不能なコードがすぐに生成される可能性があります。数学では、演習は純粋にアカデミックであるため、そのような問題はありません。しかし、時は金なりの製品コードでは、非常に簡潔なコードが何をしているのかを人々に理解させようとすることはあまり意味がないようです。もう少し冗長なコードでは、読みやすさと節約が得られます。
どの時点でソフトウェア コードの圧縮を停止しますか?
私は、自分のプログラム ステートメントがプログラマーなら誰でも理解できる文のように読めるレベルの冗長さに到達しようとしています。これは、すべてが短いストーリーになるようにコードを大幅にリファクタリングすることを意味するため、各アクションは個別のメソッドで記述されます (さらに別のレベルは別のクラスになる可能性があります)。
つまり、表現できる文字数が少ないからといって、文字数を減らすわけではありません。それがコードゴルフ大会の目的です。
私のルールは、あなたが何を意味するかを言うことです。私がよく目にする失敗例の 1 つは、「筋力低下」です。基本的に、彼らは自分が考えているコンセプトを、ステップをスキップしているように見えるものに置き換えます。残念ながら、コードから概念を除外しているため、読みにくくなっています。
たとえば、
for (int i = 0; i < n; i++)
foo[i] = ...
に
int * p = foo, q = foo+n;
while ( *p++ = ... < q );
は、ステップを節約するように見える強度削減の例ですが、foo が配列であるという事実を除外しているため、読みにくくなっています。
もう 1 つの一般的な例は、enum の代わりに bool を使用することです。
enum {
MouseDown,
MouseUp
};
これを持って
bool IsMouseDown;
これがステート マシンであるという事実が除外されているため、コードの保守が難しくなっています。
したがって、私の経験則では、実装では、表現しようとしている概念よりも低いレベルまで掘り下げないでください。
冗長性を見つけて削除するか、賢くすることで、コードを小さくすることができます。後者ではなく前者を行います。
Steve McConnell による優れた記事 - Best Practices http://www.stevemcconnell.com/ieeesoftware/bp06.htm
短く/簡潔なのは、適切に記述されたコードから得られる 2 つの結果だと思います。優れたコードを作成するには多くの側面があり、適切に記述されたコードから多くの結果が得られます。この 2 つが異なることを認識してください。コンパクトなフット プリントを計画するのではなく、簡潔で 1 つのことを非常にうまく実行する関数を計画します。以下は、コードを書く際に私が注目することの短いリストです。
バランスを見つける 1 つの方法は、簡潔さではなく読みやすさを求めることです。プログラマーは常にコードを視覚的にスキャンして何が行われているかを確認しているため、コードは可能な限りスムーズに流れる必要があります。
プログラマーがコードをスキャンしていて、理解しにくいセクションに出くわしたり、視覚的に解析して理解するのに多少の労力がかかる場合、それは悪いことです。よく理解された一般的な構造を使用することが重要です。必要な場合を除き、あいまいで頻繁に使用されないものは避けてください。
人間はコンパイラではありません。コンパイラはそれらを食べて、先に進むことができます。あいまいなコードは、明確に理解されたコードほど速く人間によって精神的に消費されません。
複雑なアルゴリズムで読み取り可能なコードを生成するのが非常に難しい場合もありますが、ほとんどの場合、賢さではなく、人間の読みやすさが求められるべきです。コードの長さは、実際には明確さの尺度ではないと思います。より詳細なメソッドは簡潔なメソッドよりも読みやすい場合があり、簡潔なメソッドは長いメソッドよりも読みやすい場合があるためです。
また、コメントは補足するだけで、コードを説明するのではなく、コード自体を説明する必要があります。何が行われたかが明らかでないために行にコメントしなければならない場合、それは悪いことです。ほとんどの経験豊富なプログラマーは、コード自体を読むよりも英語の説明を読む方が時間がかかります。Code Completeという本は、これを思い起こさせると思います。
オブジェクト名に関する限り、これに関する考え方は、新しいプログラミング言語の導入により進化を遂げました。
C で始まる「中括弧」言語を例に取ると、簡潔さは機知の魂と見なされていました。したがって、たとえば、「lv」という名前のローン値を保持する変数があります。大量のコードを入力していたので、キーストロークを最小限に抑えてください。
その後、Microsoft が承認した "ハンガリー表記" が登場しました。変数名の最初の文字は、その基になる型を示すためのものでした。「fLV」などを使用して、ローンの値が float 変数で表されたことを示す場合があります。
Java、そして C# によって、パラダイムは明確なものになりました。ローン値変数の適切な名前は「loanValue」です。この理由の一部は、ほとんどの最新のエディターのコマンド補完機能にあると思います。名前全体を入力する必要がなくなったため、説明に必要なだけ多くの文字を使用することもできます。
これは良い傾向です。コードは理解できる必要があります。コメントは、たとえあったとしても、後付けとして追加されることがよくあります。また、コードが更新されても更新されないため、古くなります。説明的で適切に選択された変数名は、コーディングの内容を他の人に知らせる最初の、最良かつ最も簡単な方法です。
「私たちはエンジニアとして、これまでにない種類のものを常に作成しています。私たちが付けた名前は長く残るので、意味のある名前を付けるように注意する必要があります。」
コード自体が読みやすくなるまで、リファクタリングに努めてください。その過程で自分自身の間違いを発見し、「次の人」がコードを理解するのがより簡単になり、すでに表現されていることをコメントで維持する (そして後で変更するのを忘れる) ことで負担がかからなくなります。コード。
それが失敗した場合...もちろん、コメントを残してください。
そして、コメントで「何」を言わないでください（それがコードの目的です）、「理由」を教えてください。
DRY : 繰り返さないでください。これにより、簡潔で安全なコードが得られます。同じコードを何度も書くことは、保守を難しくする良い方法です。
これは、リモートで似ているコード ブロックの関数を作成する必要があるという意味ではありません。
たとえば、非常に一般的なエラー (ホラー ?) は、ほぼ同じことを行うコードを因数分解し、関数 API にフラグを追加して発生間の違いを処理することです。これは一見無害に見えるかもしれませんが、理解が難しくバグが発生しやすく、リファクタリングがさらに困難なコード フローを生成します。
一般的なリファクタリング ルール (コードの匂いを調べる) に従うと、多くのコードの匂いが冗長性の検出に関するものであるため、副作用としてコードがより簡潔になります。
一方、意味のあるガイドラインに従わずにコードをできるだけ短くしようとすると、コードを削減する方法がわからなくなるため、ある時点で停止する必要があります。
最初のステップで不要な空白をすべて削除することを想像してみてください...その後、ほとんどのプログラミング言語のコードが読みにくくなり、他の可能な拡張機能を見つける機会があまりなくなります。
上記の例は非常に風刺的ですが、適切なガイドラインに従わずにサイズを最適化しようとしたときに得られるものからそれほど離れていません.
長い/とりとめのないものとは対照的に？もちろん！
しかし、あまりにも短く簡潔すぎて理解するのが難しい場合は、行き過ぎです。
はい。いつも。
コードの最適化は、コーディング スタイルとはほとんど関係ありません。ファイルに含まれる x スペースまたは改行が最初よりも少ないという事実は、少なくとも実行段階では、改善または高速化にはなりません。コンパイラによって異常に無視される白い文字でコードをフォーマットします。他のプログラマーや自分自身が読めなくなるため、コードがさらに悪化します。
テスト条件、制御フロー、前提条件、エラー処理、またはプログラミング インターフェイス全体など、コードがその論理構造において短く簡潔であることがはるかに重要です。もちろん、スマートで役立つコメントとドキュメントもここに含めます。
最適化をいつ停止するかを決定するいくつかのポイントがあります。
最適化の実行に時間を費やす価値があります。何週間も費やしても何も見つからない人がいる場合、それらのリソースのより良い使い方はありますか?
最適化の優先順位は何ですか。コードに関しては、いくつかの異なる要素を考慮することができます: 実行時間、実行スペース (実行中のコードとコンパイルされたコードのみの両方)、スケーラビリティ、安定性、実装されている機能の数など。時間と空間のオフですが、一部のコードがどこに行くのか、たとえば、ミドルウェアがアドホック SQL コマンドを実行できるか、またはパフォーマンスを向上させるためにストアド プロシージャを介してそれらをルーティングする必要があるかということもあります。
要点は、ほとんどの優れたソリューションには節度があるということだと思います。
簡潔なコードとパフォーマンスの間には必ずしも相関関係はありません。これは神話です。C/C++ のような成熟した言語では、コンパイラはコードを非常に効果的に最適化できます。そのような言語では、より簡潔なコードほどパフォーマンスの高いコードであると想定する必要があります。Ruby のようにパフォーマンスがあまり最適化されていない新しい言語には、C/C++ コンパイラのコンパイラ最適化機能がありませんが、簡潔なコードの方がパフォーマンスが優れていると信じる理由はまだほとんどありません。実のところ、コードが実稼働環境に入ってプロファイリングされるまで、実稼働環境でコードがどれだけうまく機能するかはわかりません。シンプルで無害な関数は、コード内の十分な場所から呼び出されると、パフォーマンスの大きなボトルネックになる可能性があります。並行性の高いシステムで最大のボトルネックは、一般に、不十分な並行性アルゴリズムまたは過剰なロックによって引き起こされます。
要するに、パフォーマンスの低いコードは、プロファイリングによってボトルネックであると判断されれば、いつでもリファクタリングできます。コードは、理解しやすい場合にのみ効果的にリファクタリングできます。「簡潔」または「巧妙」に記述されたコードは、多くの場合、リファクタリングと保守がより困難になります。
人間が読みやすいようにコードを記述し、必要に応じてパフォーマンスのためにリファクタリングします。
私の2セント...
巧妙なコードと華麗なコードを区別するための正確な線引きはありません。最善の判断を下してください。他の人にコードを見てもらい、どれだけ簡単に理解できるかを確認してもらいます。ただし、正確さが一番の目標であることを忘れないでください。
コードは短く、具体的で、集中している必要があります。コメントでは、いつでも自分のアイデアを多くの言葉で説明できます。
コメントする限り、コードを好きなだけ短くまたはコンパクトにすることができます。このようにして、コードを最適化できますが、それでも意味があります。私は変数とメソッドを記述し、まだ不明な場合は控えめなコメントでどこかにとどまる傾向があります。