回答:
「少ないライン」は、「より効率的な」と常に同じではありません。「読みやすさを犠牲にしてプログラムを短くすべきだ」という意味だと思います。
プログラムは、人々が読むために、そして偶然にマシンが実行するためだけに書かれなければなりません。
-Abelson＆Sussman、コンピュータープログラムの構造と解釈
一般に、プログラムが短いことよりも、プログラムを簡単に理解することが重要だと思います。ただし、プログラムを短くすると読みやすくなることもよくあります（コードがラインノイズのように見え始めたときに到達する明確なしきい値がありますが、それまでは、何かを簡潔に表現することでより明確になります）。
特定の例外（個人用シェルスクリプトやデータ変更コードなど）には、誰も管理する必要がなく、あなただけが読む必要があります。その状況では、理解しやすい限り、利便性のために読みやすさを犠牲にしても大丈夫でしょう。
時々、はい。
読みやすさを追求するのは良いことです。典型的な基幹業務アプリケーション用に記述されたほとんどのコードは十分なパフォーマンスを発揮するため、読みやすさに重点を置くことが重要です。よりパフォーマンスが要求される領域（ビデオゲームプログラミングや重い計算など）では、読みにくいので、ひどく読めないが、信じられないほどパフォーマンスの高い特定の言語機能を使用することが重要です。
後者の例については、Wikipediaの記事「高速逆平方根」を参照してください。
私は一般的に、O（n）よりもO（n ^ 2）アルゴリズムを選択しないなどの常識的な予防措置を講じれば、最初に何かを読みやすくしてパフォーマンスを心配する方が良いと思います。簡潔さのためだけに読みやすさを犠牲にすることは、私の考えでは見当違いです。
コードの効率性とコードの可読性を犠牲にする必要がありますか？
コードに関しては、自己文書化することは常に素晴らしいことです。しかし、時にはそれが起こらないこともあります。最適化する必要がある場合もあれば、コード自体が読みにくい場合もあります。
これはコメントが発明されたものですです。それらを使用します。アセンブリにもコメントがあります。大量のコードを作成していて、コメントが表示されない場合は、心配です。コメントは実行時のパフォーマンスには影響しませんが、何が起こっているかについてのいくつかのメモが常に役立ちます。
私の心では、いくつかの基本的なコメントをしないことの言い訳は絶対にありません。明らか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行に
特にひどいアイデア。
コードゴルフをプレイするためのコスト-非常に高い。
読めないプログラムを維持するためのコスト-天文学的。
この種の最小化コードの値-ゼロ。それでも動作しますが、「より良い」動作はしません。
賢明に選択された効率
適切なアルゴリズムとデータ構造を選択するためのコスト-中程度。
適切なアルゴリズムとデータ構造を維持するためのコスト-低。
適切なアルゴリズムとデータ構造の価値-高い。リソース使用量が少ない。
愚かな（「マイクロ最適化」）効率
マイクロ最適化を行うためのコスト-高い。
読み取り不可能な、最適化されたコードを維持するためのコスト-非常に高い。
マイクロ最適化の価値-さまざまです。ここにゼロ以外の値がある場合でも、コストはそれを上回ります。
コードの実行速度という点で効率性について話しているのか、開発者がコードを記述できる速度の効率性について話しているのかによって異なります。コードを非常に高速に入力できるようにコードの読みやすさを犠牲にしている場合、デバッグの面で時間を費やしていることに気付くでしょう。
ただし、コードの実行速度の観点からコードの可読性を犠牲にすることについて話している場合、コードが効率的な方法で実行されなければならない限り、容認できるトレードオフになる可能性があります。パフォーマンスが重要な高速逆平方根のようなものだからといって、できるだけの理由でできる限り高速に実行するものを書くのは、ほとんど理由がありません。秘Theは、コードのバランスを取ることと、ソースが読みにくい場合でも、それが何をしているのかを説明するコメントが何が起こっているのかを説明することを確認することです。
コンパイラーは非常に賢い（ほとんどの開発者よりも賢い）か、マシンがとてつもなく高速であるため、コードを高速化するはずでしたが、コードを読みにくくする多くのトリックはもう必要ありません。
「パフォーマンスよりも読みやすい」という議論は受け入れません。 別のスピンを使って回答をさせてください。
いくつかの背景：何が私を病気にしているのか知っていますか？[マイコンピューター]をダブルクリックすると、実際にコンピューターが表示されるまで待機する必要があります。5秒以上かかると、本当にイライラします。馬鹿げたことは、これをMicrosoftのせいにしているだけではありません。それは、場合によっては時間がかかる理由は、表示するアイコンを決定する必要があるからです。そのとおり。だからここに座って、C：ドライブに行くことにだけ興味があり、ドライバーがCD-ROMにアクセスしてそこからアイコンを読むのを待つ必要があります（ドライブにCDがあると仮定して）。
OK。だから、私のコンピューターをダブルクリックし、ドライバーを介して実際にCD-ROMと通信する間のすべてのレイヤーを想像してみてください。今、すべてのレイヤーが...より速く...
おわかりのように、これらのすべての背後には、コードが「読みやすい」ため、何千人もの幸せなプログラマがいます。それは素晴らしいことです。私はあなたのために幸せです。しかし、ユーザーの観点からすれば、それは単に技術的な用語です。そして、あなたはコードをより読みやすく、しかも遅くすることで正しいことをしたと自分に言い聞かせて夜眠ります。それができるよりも少し遅いです。そして、何千人もの開発者がこれを行い、あなたのために私たちのPCを待つことになります。私の意見では、あなたは価値がありません。あなたの最初の行が最高である必要があると言っているのではありません。
私のアプローチは次の とおりです。 まず、動作させてから、高速化します。常に効率的なコードを書くことを目指し、読みやすさを犠牲にする必要がある場合は、コメントを追加してください。平凡なプログラマーがそれを維持できるように、効率を犠牲にしません。ただし、コードについて説明しますが、それだけでは不十分な場合は、申し訳ありませんが、ここで作業するのは無能です。ここでは、高速で読みやすいコードを記述しており、バランスは取れていますが、読みやすいコードは説明できますが、非効率性は容認できません。
この質問は、面接がオフィスで議論されるときによく思い浮かびます。何年も前に卒業生として、「コードは自己文書化されていると思いますか？」という質問を受けました。さて、私はプログラマーとしてこの質問に答えるつもりでしたが、インタビュアーに関する限り、それは白黒の質問であったため、妥協点はありませんでした。人々は活発に行き来し、できるだけ早く新しいスタートを準備したいので、プロセスは個々の人よりも長生きする必要があり、コードが読みやすいほど、何が起こっているかをより早く理解することができます。
ドメイン駆動開発：ドメイン駆動設計：ソフトウェアの中心にある複雑さへの取り組みと呼ばれるかなり良い本をしばらく読んだことがあります。これは、適切に文書化するシステムにつながる優れたアプローチを示しています。言語はソリューションを伝達するための媒体であるため、ソリューションが明確に表現されるほど、パフォーマンスが重要な要因になった場合に適応しやすくなります。それが私の信念であり、私にとってはうまくいったようです。
読みやすさを犠牲にしてコードをより高速に実行するためのROIに値することはめったにありません。現代のコンピューターは非常に高速で実行されるため、これが必要なシナリオがあるとは思いません。コンピューターがコードを実行している場合、そのコードを維持する必要があります。
そのためには、読みやすさが非常に重要だと思います。もちろん、何度も述べたように、コードが読みやすいからといって、それが遅くなることを意味するわけではありません。
良い例は変数名です： $a
なに$a？これはコンテキスト外であるため、それに答えることはできませんが、実際のコードでこれに遭遇したことはありますか？今、誰かが書いたと仮定します$file_handle-それは何ですか？コンテキスト外であっても明らかです。変数名の長さは、コンピューターにわずかな違いをもたらします。
ここには常識があると思います。
一部のアプリケーションでは、すべてが理解できるわけではないビットシフトのショートカットが必要になる場合がありますが、ある時点で収益が減少し、シナリオを見つけることはまれだと思います*。
*これは、業界などの事項に依存します。これをビジネスソフトウェア開発者（ビジネス情報システム）の観点から見ています。
これをさらに別の観点から（ただし、とりとめなく）見るために、私はSAASを行う会社で働いています。サイトがダウンしたとき、私たちは本当に、本当に速くそれを修正しなければなりません-通常、他の誰かが別の開発者のコードを修正しています。
私はずっと、むしろ誰か非常に非効率的に何かをするが、それ空想と「速い」を作ることよりも読みやすいです。Webサーバーは最先端であり、100万分の1秒でリクエストを送信する必要はありません。負荷の問題はありません。
だから、実際には、あなたは自分自身や他の人を傷つける可能性が高いと思います...（私は週末を取り戻したいです）
ほとんどの場合、答えは「コンパイラーにその仕事を任せて」と読み、読みやすいコードを書くことです。これは、コードが論理的に構造化されている（つまり、スパゲッティがない）ことと、自己文書化（つまり、変数、関数などの十分に明確な名前）であることを意味します。意味のあるコメントで自己文書化されていない補足コード。コメントのためにコメントしないでください。つまり、
x++; // Add one to x
むしろ、読者であるあなたに、6か月、12か月、または他の十分に長い時間でコメントしてください。コーディング標準を採用し、それに従ってください。
クリーンコードは高速なコードです。プログラマーが手元のタスクを理解し、コードをそのコアの目的にリファクタリングしたことを示す指標であるため、明確に記述された、保守が容易なコードは高速になる傾向があります。
さらに、最新のコンパイラーは命令を非常に効果的に最適化します。何かをするために入力するコードの行数と、命令に関してコンパイラが作成するものは、必ずしも関連しているわけではありません。コンパイラーを読んで、なぜそうなのかを理解してください。
グラフィックなどのパフォーマンスベースの何かに取り組んでいるとき、小さな最適化が大きな効果をもたらす可能性のある最も深いネストされたアルゴリズムに取り組んでいるときに、画像処理のようなことをするとき、読みやすさ/保守性を犠牲にすることがあります。そしてそれでも、変更が実際にスピードアップすることを確認するために、プロファイリング後にのみそうします。コンパイラーが手動で入力したコードを最適化した方法のために、実際にアプリの速度が低下したことを見つけるために、手動で「最適化」を試みた回数を説明することはできません。
読みやすさは、無能で怠zyなプログラマーの言い訳です（実際には、安易なアルゴリズム/設計を守るための引数として使用される場合、「単純さ」にも同じことが当てはまります）。
与えられた問題ごとに、最適な解決策を模索する必要があります！今日のコンピューターが高速であるという事実は、CPUサイクルを浪費する言い訳にはなりません。唯一の制約は「納期」です。ここで言う「最適なソリューション」とは、あなたが思いつくものを意味することに注意してください（私たち全員が最良のソリューションを思い付くことができない、またはそれらを実装するスキル/知識を持っているわけではありません）。
ソリューションの「理解しにくい」側面がある場合、他の誰かが言及したように、それがコメントの目的です。他の誰かが言及した「正しい、読みやすい、速い」という順序（またはそのようなもの）は、時間の無駄です。
そこにプログラマーがいると信じるのは本当につらい時があります。プログラマーは、問題を提示されたときに、「...これはこのようにする必要がありますが、効率的ではないが読みやすい/保守可能なその他のがらくた...」これの誤りは、次の開発者（非効率性を見て）がコードを変更する可能性が高く、次の開発者も同じことを行うということです。最終結果は、数バージョン後にコードが元のものになることです。開発者は1位に書かれている必要があります。元の開発者の唯一の言い訳はaです。彼/彼女はそれを考えていませんでした（十分に公正）と（前述のように）b。時間とリソースの制約。