コードの行数を減らすことはどれほど重要ですか？

私はJ2SE（コアjava）で作業するソフトウェア開発者です。
多くの場合、コードレビュー中に、コードの行数を減らすように求められます。

冗長なコードを削除することではなく、コード内の少ない行で同じことを行うことに焦点を当てたスタイルに従うことです。行の数を増やすことを意味する場合でも、コードを明確にすることを信じています。

物事を行う正しい方法は何だと思いますか？
LOC（コード行）が小さい場合、コードにどのような影響がありますか？LOCの数値が大きい場合、コードにどのような影響がありますか？

ウェブサイトからの例： "javaranch"-

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

測定の問題は、それらがどれほど良く意図されていても、アイテムを測定するという行為そのものが重要であり、当然のことながら、アイテムを測定しないという行為は重要ではありません。重要なものを測定し、重要でないものを測定することは絶対に不可欠です。

SLOCを測定すると（実際にレビューが行っていることはどれですか）、SLOCは重要になります。...SLOCは重要ですか？-絶対にそうではなく、（難読化されたプログラミングコンテスト以外で）一度も行われたことはなく、営利団体に参加することは決してありません。

1つの簡単な質問を自問してください。「このルーチンのSLOCを削減する」ことで、どのようにコードが改善されますか。この場合におそらく起こっているのは、複雑さを測定するための単純な方法としてSLOCが使用されていることです。すべてのコストで回避する必要があるのは、カウントしやすいビーンをカウントすることです-重要度をカウントするのではなく、SLOCなどの客観的な測定値ですが、カウントしにくい-たとえば、読みやすさ、複雑さなど

コードレビュー担当者に同意しますが、アスタリスクに同意します。コードに記述する各ステートメントは技術的な責任です。潜在的な障害点です。メソッドを10個のステートメントで記述し、同僚が5個のステートメントで同じ機能を実現するメソッドを記述した場合、問題の可能性で測定すると「より良い」可能性が高くなります（コードが間違っている可能性のある場所が2倍あります複雑、または問題があります）。

ただし、ここにアスタリスクがあります。以下のようなもので行数を減らすことができるため、アイデアの実際のコード行数ではありません。

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

これは1行のコードですが、驚くべき量の問題が発生する可能性のある場所です。だから、最小限のステートメントで最大限の成果を上げることに焦点を当てる-物事を成し遂げるために必要なだけコードを書き、それ以上はしない。少なくとも、それはあなたのコードレビュー担当者が推進していることだと思います。

個人的には、バランスを取るべきだと思います。私が言ったように、あなたが書くそれぞれのステートメントは責任がありますが、説明的な名前を持つローカル変数を引き出すと、メソッドがより明確で読みやすくなる場合は、そのためのケースもあります。人々は比較的小さな審美的な違いを口論する状況に簡単に入ることができると思いますが、全体として、あなたのレビュアーは正しい考えを持っていると思います。

明らかな直接的な結果は、簡潔なワンライナーを促進することであるため（ラインの長さの制限にもかかわらず）、レビュアーのアドバイスに従うことは文字通り何の役にも立ちません。ただし、ここで学ぶべき教訓は、コードの実行回数を減らすことです。

言い換えれば、これは単純さを求める呼びかけです。コードは資産ではなく負債であるという非常に一般的な主張であるため、機能を維持しながらその量を減らすことは気高い努力です。これは、問題に直接対処し、簡潔なソリューションを好む、より現実的な直接的なアプローチによって実現できます。

ケン・トンプソンがかつて言ったように：私の最も生産的な日々の1つは1000行のコードを捨てることでした。

「行数を増やすことを意味する場合でも、コードを明確にする」というあなたの立場に同意する傾向があります。

かなり簡潔なワンライナーがあまりにも多く見られましたが、彼らが何をしているのかすぐにはわかりません。他の開発者がコードを保守する必要があるため、読みやすさが重要です。

私が目指すべきより良いものは短い方法であると主張します。数行のコードのために短くはありませんが、1つのことを行うため短いです。

私は現在、大手企業のシニアアプリケーション開発者およびプロジェクトビジネスアナリストとして働いており、開発の行数が関心の中心になったことはありません。ただし、コードを簡潔にすればするほど良いのではないかと思いますが、コードをすばやく分析して修正（または追加）できるという犠牲はありません。膨大なレベルのスケーラビリティを持ち、絶え間なく変化する環境でオンザフライで変更できるビジネスクリティカルなアプリケーションを担当している場合、簡潔で読みやすいコードは開発の最も重要な要素の1つです。エリック・ディートリッヒの回答の功績、これは：

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

私にはまったく受け入れられないでしょうが、私はすべての企業の既存のコードを変更することがわかりました：

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

に：

value.prop =  boolean ? option1 : option2;

読みやすさを犠牲にしない優れたコード圧縮の選択でした。

コードにどのように影響するか？100行のコードによるパフォーマンスの向上や低下に気付いたことはありません。簡単な事実は、最終製品に到達するまでにかかる行数よりも、最終製品に到達するために利用するプロセスのほうが多いということです。いくつかのプロセスは非常に簡潔に記述されていますが、非効率ですが、より長いコードとは異なるコードフローでパフォーマンスが異なります。

IMO、ささいなLOCカウントでコードの有効性を測定するのは悪い考えです。適切に設計された効果的なコードを作成するものには、さらに多くのことがあります。

私の経験では、効果的なコード：

• 固い原則を破らない
• 読みやすく、一目瞭然
• アルバートアインシュタインのシンプルさのテストに合格します：「すべてをできるだけシンプルにする必要がありますが、シンプルではありません。」

ここには、LOCを抑える技術的な長所と短所、およびLOCが有意義な品質のソフトウェアメトリックであるかどうかに対処する多くの回答があります。それはこの質問の目的ではありません。それは、特定のコーディングルールの素朴な独断的な遵守を主張する管理に対処する方法です。

悲しいことに、適切なコンテキストで使用されて実用的に適用されたときに良いアドバイスであるものをラッチし、そのコンテキストからそれらを取り出して独断的に適用する一方で、アドバイスが最初に軽減するために存在する問題を認識しないことがかなり一般的です。

LOCを維持することに関するアドバイスの目的は、一度に多くのことをしようとするメソッドの作成を避け、「神のクラス」の作成を思いとどまらせることです。システム内の他のすべてのクラスが依存している直接的な責任。短いコードのもう1つの利点は、コードが読みやすいことです。ただし、指摘したように、読みやすさが実際に低下し始めるまでやり直すことができます。

少ないLOCカウントには明らかな利点があります（小さなメソッドは大きなメソッドよりも簡単に頭に収まります、コード内の要素が少ないほど、失敗する可能性が少なくなります）。しかし、それはまた、収益の減少の法則に従います。150行のメソッドを20行のメソッドにリファクタリングすることは、10行のメソッドを7行のメソッドにリファクタリングするよりもはるかに大きな勝利です。

そのようなリファクタリングが、優れたソフトウェア設計の他の側面（読みやすさなど）を犠牲にして行われる場合、それを行わないことを正当化できるポイントに到達しました。コードの意味にコンテキストを与える変数を削除し、そうでないリテラルに置き換えることは非常に悪いことです。良いコードにはリテラルがほとんどありません。ただし、これらの変数（および名前付き定数）は、プログラムに直接寄与しないコードの行であるため、LOCが何らかの神として崇拝されている場合、そのような明確化の行は、迅速な勝利のために刈り込まれ、経営陣からの見当違いの称賛。

私はあなたがこれを実現するのに十分賢いと信じています。実際、それはあなたの元の質問のほとんどの推力です。問題は、コード削減がいつよいかを理解することではありません。そうでない場合、問題は、通常合理的な実践を無差別に適用する際の独断です。

時間をかけて経営陣とチャットをして、自分の立場と、あなたが求められていることがコードに役立つのではなく害を及ぼすと思う理由を説明することをお勧めします。対立することは避けましょうが、そのような議論の間は合理的で落ち着いたままにしてください。プログラミングは実用的な活動であることを経営者が理解することが重要です。ベストプラクティスのアドバイスは、実用的な方法で適用された場合にのみ有用です。ベストプラクティスは、石に刻まれたものではなく、本に書かれており、競合する場合（短いコードと読み取り可能なコード）、どのベストプラクティスに従うかを判断するのはプログラマー次第です。うまくいけば、彼らはこのような入力に感謝する合理的な人々です。

また、LOCを不必要または不適切であると思う場所でLOCを削減するようにプレッシャーをかけられている場合は、静かな生活のためにとにかく変更を加えるのが自然であるため、少し勇敢であることも必要です。これに抵抗する必要があり、その決定を「所有」する必要があります。管理が合理的である状況では、ガイドラインを厳密に順守する必要はありませんが、そうでない状況を正当化できるはずです。

悲しいことに、人々は不合理になる可能性があります。特に、決定やあなたに課したルールに疑問を投げかける序列の方が低い場合はそうです。彼らは合理的でないことを選択するかもしれません。あなたもそのために準備する必要があります。LOCのベストプラクティスが他のベストプラクティスと直接競合するケースと、それが製品を傷つけている理由を示すことができ、コードベースの個人的な関与がほとんどまたはまったくない部分でそれを行うことができる場合（したがって、 「彼らの仕事や監督している仕事に対する個人的な攻撃のようには見えない）、これはあなたの議論を強化するのに役立つかもしれません。繰り返しますが、あなたは冷静で合理的な方法で自分を正当化する準備ができていて、あなたが作っている議論を「所有する」ことができなければなりません。

あなたの経営陣が合理的な人であれば、彼らはあなたの主張を裏付ける証拠を提供できるなら、あなたが言っていることが価値があることを認めなければなりません。

少数のSLOCで機能を持つように努力する必要があると思います。

LOC（コードの行）が小さい数である場合、コードにどのように影響し、LOCが大きい数である場合、コードにどのように影響しますか？

理想的には、30行を理解するよりも、8行のコードをひと目で理解する方が簡単です。

これは、8行に圧縮された30 LOCが理解しやすいという意味ではありません。

あなたは物事を行う正しい方法だと思います。

通常、関数では、抽象化のレベル（「ここにIOコード」、「ここに検証」、「ここに計算」など）でグループ化しようとします。

次に、空白行で区切ってブロックに分割します。コードが約10行を超える場合は、各ブロックを異なる関数に抽出します（とにかく、複数回出現するコードに対してそれを行います）。この方法でパフォーマンスを壊す（不必要な関数呼び出し）という議論を聞いたことがありますが、実際には、これによってパフォーマンスのボトルネックが発生したことはありません。

とは言っても、この抽出を行った関数はありましたが、関数の長さは約40行（Cコード）でした。コードが可能な限りグループ化されている場合、より長い関数で問題は発生しません。

LOCよりも、クリーンで自動文書化されたコードに焦点を合わせることが重要だと思います。ただし、コードが何をしているのかを、理由は言うまでもなく説明しているので、私はあなたの例が本当に好きではありません。たとえば、これ：

boolean sweet_sixteen =（年齢== 16）;

かなり冗長です。「年齢== 16」を読んでいる人なら誰でも知っています。私はむしろこのようなコードを書きたいです：

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

パーティーをスローするタイミングを決定するロジックはSystem.outとは別のものであり、テストすることができ、理解するのは簡単です。しかし、もっと重要なのは、コードを読んでいる人は、そのように書かれた理由を理解できることです（「会社は、一部の人々のために大きなパーティーを開きたい」）。

少ないコード行=より読みやすいコードだと思う

しかし、もちろん、行を少なくするためだけにコードを縮小/不明瞭にし始めると、ある程度の制限があります。

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

これは、ロジックが同じままで、読みにくいだけの縮小です。これは人間によって行われるべきではなく、この縮小は機械によって行われ、機械によって読み取られます。

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

コードの一部を削除できても、アルゴリズムが想定どおりに機能している場合は、先に進みます。コードを縮小しないでください。それを行うためのより良いツールがあります。

コードの行数が少ない==より読みやすいコードだとは思いません。ただし、理論とは非常に異なる現実は、多くの行を含むコードが適切な設計なしで記述されることが多いということです。その結果、より少ない行の要件により、一部のプログラマーは、可能であればより良い設計を思い付くことがあります。ひねりは、多くのプログラマーがそうではないということです、そして、要件はあまり役に立ちません。

行の数は通常の状況では問題としては見えませんが、問題を指し示すことができます。誰かが1000行のコードを含むクラスを表示する場合、クラスの実行方法または設計方法に何か問題があるに違いありません。

あなたの例は、コードの行数が多いほうが理にかなっている場合を示しています。しかし、それはその例です。毎日、行数が計画の欠如に関係している例を見る

LOCは、実際の実装時よりもプロジェクトの開始時の方がはるかに便利な指標です。機能ポイントごとのLOCを知ることで、プロジェクトの労力、およびそこからプロジェクトにかかる時間と最適な開発者数を見積もることができます。

また、設計と言語の選択に影響を与える可能性があります。機能ポイントを減らすか、LOC / FPの低い言語に切り替えると、プロジェクトの労力を減らすことができます。

コードの行自体はあまり重要ではありません。それを見る一つの方法は、それを散文と比較することです。最初の認識は、コードと散文の両方の重要な特性（正確性を前提とする）は可読性であるということです。読みやすさ（および理解可能性）は、保守性や正確性などの他の特性に役立ちます。

関数を少数の行に収めることができるという利点があります。しかし、段落のないテキストがあると読みやすさが低下します。難しい概念、難しい（まれな）単語、複雑な表現方法を使用すると、一般的にアイデアを表現するために必要な単語の量が減りますが、同時にテキストの読解レベルは中等学校レベルから専門の学者に移動します（散文の場合）。

一般に、コードに抽象化を追加してヘルパーなどを使用すると役立ちますが、これらの抽象化は非常に多くなる可能性があります。また、発生する可能性があるのは、コードの別の部分に複雑さを移すことです。エキスパートとして、ジュニアプログラマー（または学生）が使用するフレームワーク/ライブラリを設計している場合など、これを行うことをお勧めします。ただし、後輩がコードの動作を理解できるとは思わないでください。間違って使用するのは非常に困難です。

コードを書くときは、特にコードに空の行を追加することをためらわないでください。これらは段落として機能し、関数のさまざまな部分を分離するのに役立ちます（まだヘルパーに入れるべきではない場合でも）。

コード評価のすべての正式な方法の大きな問題は、一部のコードで確実に失敗することです。これは、プログラミングが一種の芸術であるため、評価のための明確な基準が存在できないためです。もちろん、さまざまな種類の芸術があります-絵画の大量生産も存在し、おそらくこのビジネスでは、1つの絵画に何個の塗料が費やされるかが重要です。:)

正直に言うと、LOC測定については言及していません。もちろん、関数やプロシージャをできるだけ短くするのは良いことですが、読み取り可能なコードは1日の短い時間で取得します。

LOCの削減を常に要求すると、コードが読みにくくなることに同意します。

ただし、コーディングスタイルが冗長すぎる可能性があり、レビュアーはより簡潔な方法の方が良いと考えています。たとえば、変数名の明確な選択のおかげでかなり明白な1つのステートメントのみを説明するコメントは役に立ちません。

コード行が測定するのは1つだけであり、それはあなたが持っているコード行の数です。それ以外はすべて熱気、憶測、偏見です。

そこに何かが悪いことではなく、改善することができ、コードの少ない行を持つかの他の回答に大きな多くの例がありますが、一つのコアポイントが見逃されているようだ、とそれはです：どのように多くの行あなたが実際に行う必要がある。この仕事をします？

タスクを完了するために10行のコードが必要な場合は、10行で実行します。それを達成するために10,000行が必要な場合、同様に10,000行で行います。「少ないコード行」のカルトはなりません、あなたが1,000 2,000または何でそれを行う場合は任意のより良い後者の例を作ります。ジョブが必要とされるだろうなど、検証、エラーチェック、セキュリティの層含み10,000行とそれらの10,000行を逃したあなたが少ない中でそれをしなかった場合を。

編集

これはいくつかのダウン票を獲得したので、私はここで言っていることについてより具体的にする必要があると思います。誰もが最初にすべきことはこれを読むことです -私があなたにそれを取り除くように頼んでいる点は、あなたが書く高レベルのコードは実際に実行されるマシンコードにほとんどまたはまったく似ていないかもしれないということです。この点の関連性は、実際に下で何が行われているのかを理解せずに高レベルのコードに焦点を当てることは見当違いです。

次のことを考慮してください。

• 本当に悪い、遅いコードをたった1行で書くことは可能です-私が提供したリンクの最後にある三項演算子のコメントに注意してください。

• コード行がAPI呼び出し（または外部ライブラリーへの他の呼び出し）を行う場合、実行されるものまたはそれがどれほど効率的であるかを直接制御する方法がほとんど定義されていません。

• エラーチェック、クリーンアップなどはすべて余分なコード行を追加しますが、より少ないコード行の最も熱心なファンであっても、それらに反論しないことは間違いありません。

だから-コード行は壊れたメトリックです。コードの行数が少なくても、追加のパフォーマンスが保証されるわけではありません。そのAPIまたはライブラリー呼び出しは1行であり、制御できない場合があります。コードの行数が少なくても、追加の堅牢性は保証されません。エラーチェックとクリーンアップには常に追加の行が必要です。コードの行数が少なくても、読みやすさや保守性が保証されるわけではありません。IOCCCを調べるだけでそれを知ることができます。

それでは、より少ないコード行で何が保証されますか？少ないコード行、それだけです。

同じ作業を10,000行ではなく2,000行で行うことに集中するのは非常に間違っています。代わりに、機能し、堅牢で、許容範囲内で実行され、読みやすく、今後も維持しやすいコードに焦点を当てます。 LoCカウントを低くして実行できることを意味する場合もあれば、LoCカウントを高くして実行する必要がある場合もありますが、LoCカウントはここでは重要ではありません。

コードの行数を減らすことはどれほど重要ですか？ほとんどの場合、まったくそうではありません。実際、ほとんどの場合、複雑な操作を読みやすいステップに分割し、各ステップをコメント化し、一般的にコメントを追加してコードを読みやすく拡張できるようにすることで、コードの行数を増やすことがより重要ですあなたの後に来る開発者。

以前は、locのコードの行数が多い場合、コードは効果的であり、使用されていたすべてのタスクを実行すると想定されていましたが、しばらくするとlocが少なくなることがわかりましたコードを実行する際にシステムが被るコストが非常に少ないため、効率性があります。したがって、システムlocの改善のためにlocを少なくする必要がありました。考慮に入れる必要があります。

1. 問題のフローチャートを作成する
2. できる限り少ないループ数を使用してみてください
3. 関数呼び出しはそれほど多くないはずです
4. スタックまたはキューを使用して関連情報を保存する場合は、TRIEなどの新しいデータ構造を使用する必要があります。
5. また、非常に大きな配列に大量の数値を格納し、配列を介してアクセスしようとする想像的な方法ではなく、現実的なアプローチで問題を解決してください。]
6. 可能な限り多くのマクロを使用するさらに使用する方法も問題に依存します。それが本当に複雑な場合、単純な方法を使用することも複雑な方法と同等です。