コードの読みやすさを犠牲にして、コードの効率を向上させる必要がありますか？
「ラインが少ない」と「効率が高い」とは必ずしも同じではありません。 「読みやすさを犠牲にしてプログラムを短くすべきか」という意味だと思います。
人々が読むために、そして偶然にマシンが実行するためにだけプログラムを書かなければなりません。
-Abelson＆Sussman、コンピュータープログラムの構造と解釈
一般的に、プログラムは短いというよりも、プログラムを理解しやすいことが重要だと思います。ただし、プログラムを短くすると読みやすくなることがよくあることに注意してください（コードがラインノイズのように見え始めると、明らかなしきい値がありますが、その時点まで、より簡潔に表現すると、より明確になるようです）。
特定の例外（個人のシェルスクリプトやデータ変更コードの1つなど）があり、誰も保守する必要はなく、あなただけが読み取る必要があります。そのような状況では、理解しやすい限り、便宜上読みやすさを犠牲にしても問題ないでしょう。
たまにそうです
読みやすさを追求するのは良いことです。典型的な基幹業務アプリケーション用に作成されたほとんどのコードは十分なパフォーマンスを発揮し、読みやすさに重点を置くことが重要です。よりパフォーマンスが要求される領域（ビデオゲームプログラミングや重い計算など）では、可読性を忘れて、ひどく読めなくても信じられないほどパフォーマンスが高い特定の言語機能を使用することが重要になる場合があります。
後者の例については、Wikipediaの Fast Inverse Square Root の記事を参照してください。
O(n)よりもO（n ^ 2）アルゴリズムを選択しないなどの常識的な予防策が講じられている場合、最初に何かを読みやすくし、パフォーマンスを心配する方が良いと私は思います。簡潔にするためだけの読みやすさは、私の考えでは誤解されています。
読みやすさを犠牲にする唯一の時間は、コードがパフォーマンスのボトルネックであることが示され、書き換えによってそれが修正されるときです。その場合、コードのintentionを十分に文書化して、バグがあった場合に簡単に追跡できるようにする必要があります。
もちろん、書き換えが読み取り不可能である必要はありません。
コードの読みやすさを犠牲にして、コードの効率を高めますか？
コードに関しては、自己文書化することは常にいいことです。しかし、時にはそれは起こり得ない。最適化が必要な場合もあれば、コード自体があまり読みにくい場合もあります。
これはコメントが発明されたものです。それらを使用してください。議会でさえコメントがあります。大量のコードを記述していて、コメントが見えない場合は、心配です。コメントは実行時のパフォーマンスには影響しませんが、何が起こっているかについてのいくつかのメモは常に役立ちます。
私の考えでは、いくつかの基本的なコメントをしない言い訳は絶対にありません。明らかにif ( x == 0 ) /* check if x is 0 */はまったく役に立ちません。あなたはコードに不必要なノイズを加えるべきではありませんが、このようなもの：
; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
Push rdp
; ...
かなり役に立ちます。
コードの読みやすさを犠牲にして、コードの効率性を高めますか？
効率が現在の目標（最適化フェーズなど）であり、ご存知の場合-指標がありますね。 -そのコード行が現在のボトルネックであり、そうです。
それ以外の場合、いいえ：可読性により、ユーザー（または別のユーザー）は後で理解しやすくなるため、後でこのコードを変更してより効率的にすることができます。
誰もコードゴルフに勝ちません
例えば3行のコードを1行に
特にひどい考え。
コードゴルフをプレイするためのコスト-非常に高い。
読み取り不可能なプログラムを維持するためのコスト-天文学的。
この種の最小化されたコードの値-ゼロ。それはまだ機能しますが、「より良い」機能はしません。
賢く選択された効率
適切なアルゴリズムとデータ構造を選択するためのコスト-中程度。
適切なアルゴリズムとデータ構造を維持するためのコスト-低。
適切なアルゴリズムとデータ構造の価値-高。リソースの使用率が低くなっています。
ばかげた（「マイクロ最適化」）効率
ミクロの最適化に取り組むためのコスト-高い。
読み取り不可能なマイクロ最適化コードを維持するためのコスト-非常に高い。
マイクロ最適化の価値-さまざまです。ここにゼロ以外の値がある場合でも、コストはそれを上回ります。
「パフォーマンスよりも可読性」の引数は受け入れません。別の見方をしてお答えします。
背景：何が私を病気にするのか知っていますか？ [マイコンピュータ]をダブルクリックすると、実際に表示されるのを待つ必要があります。 5秒以上かかると、本当にイライラします。馬鹿げたことは、Microsoftを非難するだけでなく、場合によっては、表示にどのアイコンを表示するかを決定する必要があるために時間がかかることです。そのとおり。したがって、ここに座って、C：ドライブに行くことにのみ関心があり、ドライバーが私のCD-ROMにアクセスし、そこからアイコンを読み取るのを待つ必要があります（ドライブにCDがあると仮定）。
OK。したがって、少しの間、マイコンピュータをダブルクリックして、実際にドライバを介してCD-ROMと通信している間のすべてのレイヤを想像してみてください。すべてのレイヤーが...より高速だったとしましょう...
これらすべての背後には、何千人ものプログラマーがいます。彼らのコードは「より読みやすい」からです。それは素晴らしいことです。嬉しいです。しかし、ユーザーの観点から見ると、それは（専門用語）だけです。そして、あなたはコードをより読みやすく、しかも遅いことを確実にすることによって正しいことをしたと自分に言って、夜にぐっすり眠ります。それよりも少し遅くても。そして、何千人もの開発者がこれを行っており、あなたのせいで私たちのPCを待つことになります。私の意見では、あなたはふさわしくない。私はあなたの一番最初の行が最高である必要があるとは言っていません。
これが私のアプローチです：最初にそれを機能させ、次にそれをより速くします。常に効率的なコードを書くことを目指して、可読性を犠牲にする必要がある場合は、コメントで補足してください。一部の平凡なプログラマがそれを維持できるように、効率を犠牲にしません。ただし、コードについては説明しますが、それでも不十分な場合は、申し訳ありませんが、ここで作業するだけの能力はありません。ここでは、高速で読み取り可能なコードを記述しているため、バランスはありますが、読み取り可能なコードは説明できますが、非効率性は受け入れられません。
コードの実行速度に関する効率について話しているのか、開発者がコードを書く速度についての効率について話しているのかによって異なります。コードを非常に速く入力できるようにして、コードの読みやすさを犠牲にしている場合は、デバッグに関して時間を費やしていることに気付くでしょう。
ただし、コードの実行速度の観点からコードの可読性を犠牲にすることについて話している場合、コードが効率的な方法で実行する必要がある限り、許容できるトレードオフである可能性があります。パフォーマンスが重要な 高速逆平方根 のようなものだからといって、できる限り速く実行できるものを書くのは、それほど理由がありません。トリックは、コードのバランスを取ることと、ソースが読みにくい場合でも、それが何をしているのかを説明するコメントが、何が起こっているのかを説明することの確認です。
この質問は、面接がオフィスで議論されるときによく頭に浮かびました。何年も前に、卒業生として、「コードは自己文書化されていると思いますか？」という質問を受けました。さて、私はプログラマーとしてこの質問に答えるべきでしたが、インタビュアーに関する限り、それは白黒の質問でしたので、中間的な根拠はありませんでした。人々は活発に行き来するだけでなく、できるだけ早く新しいスタートの準備をしたいので、このプロセスは個人よりも長生きする必要があります。コードが読みやすくなればなるほど、何が起こっているのかをより早く理解できるようになります。
私はしばらく前に、ドメイン駆動開発と呼ばれるかなりよかった本を読みました： ドメイン駆動設計：ソフトウェアの心臓部における複雑性への取り組み 確かに、それは最初は少しドライな読みですが、資料はよく提示されています。これは、自分自身を文書化するシステムにつながる良いアプローチを示しています。言語はソリューションを伝えるための媒体です。そのため、ソリューションが明確に表現されているほど、パフォーマンスが重要な要素になった場合に適応しやすくなります。それが私の信念であり、私にとってはうまくいったようです。
コードを高速にするはずの多くのトリックは、コードを読みにくくする傾向がありますが、コンパイラー 非常に賢い（ほとんどの開発者よりも賢い） またはマシンがばかばかしいほど速くなるため、もう必要ありません。 。
読みやすさを犠牲にしてコードの実行を高速化することによるROIが価値あるものになることはほとんどありません。最近のコンピューターは非常に高速で動作するので、これを必要とするシナリオがあるとは思えません。コンピュータがコードを実行している場合、そのコードを保守する必要があります。
そのためには、読みやすさが非常に重要だと思います。もちろん、何度も述べたように、コードが読み取り可能だからといって必ずしも低速である必要はありません。
良い例は変数名です：$a
とは $a ??これは文脈外なので、答えることはできませんが、実際のコードでこれに遭遇したことはありますか？誰かが$file_handle-今それは何ですか？それは文脈から外れても明らかです。変数名の長さは、コンピューターにとって重要ではありません。
ここには常識があると思います。
一部のアプリケーションでは、すべてが理解できるわけではないビットシフトショートカットが必要になる場合がありますが、ある時点で収益が減少し、シナリオを見つけることはまれであると思います*。
*これは業界やその他の要素に依存します。これは、ビジネスソフトウェア開発者（ビジネス情報システム）の視点から見ています。
これをさらに別の観点から見るために（ただし混乱しないため）、SAASを行う会社で働いています。サイトがダウンしたときは、本当にすばやく修正する必要があります。通常、他の誰かが別の開発者のコードを修正しています。
私はmuchだれかが非常に非効率的に何かを行いますが、それを空想的で「高速」にするよりも読みやすいです。私たちのウェブサーバーは最先端であり、リクエストは100万分の1秒で配信される必要はありません。読み込みの問題はありません。
ですから、実際にはあなた自身や他の人を傷つける可能性が高いと思います...（私はむしろ私の週末を取り戻したいと思います。）
ほとんどの場合、答えは「コンパイラにその仕事を任せる」であり、読みやすいコードを記述します。これは、コードが論理的に構造化されており（つまり、スパゲッティがない）、自己文書化されている（つまり、変数、関数などの名前が十分に明確である）ことを意味します。意味のあるコメントで自己文書化されていない補足コード。コメントのためにコメントしないでください。
x++; // Add one to x
むしろ、読者、読者のために、6か月、12か月、または他の十分長い時間でコメントしてください。コーディング標準を採用し、それに従ってください。
クリーンなコードは高速なコードです。明確に記述され、保守が容易なコードは、プログラマーが目前のタスクを理解し、コードをその中核的な目的にリファクタリングした指標であるため、より高速になる傾向があります。
さらに、最新のコンパイラーは非常に効果的に命令を最適化します。何かを行うために入力するコードの行数と、コンパイラーが命令に関して作成するコードは、必ずしも関連しているわけではありません。コンパイラについて読んで、なぜそうなるのかを理解してください。
グラフィックスなどのパフォーマンスベースの作業をしているとき、小さな最適化が大きな影響を与える最も深いネストされたアルゴリズムで作業しているときに、画像処理などを行っているときは、読みやすさや保守性を犠牲にすることがあります。そしてそれでも、変更を確実にするためにプロファイリングの後でのみ実際にスピードアップします。コンパイラーが手動で入力したコードを最適化した方法が原因で実際にアプリの速度が低下していることを確認するためだけに、手動で「最適化」をコーディングした回数はわかりません。