コードの行数を減らすことはどれほど重要ですか？
私は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つです。 。 Erik Dietrichの返信 のおかげで、これは：
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カウントでコードの有効性を測定することは悪い考えです。適切に設計された効果的なコードを作成するためには、さらに多くのことが必要です。
私の経験では、効果的なコード：
- SOLIDの原則 のいずれにも違反しない
- 読みやすく、自明です
- アルバートアインシュタインのシンプルさのテストに合格：「すべてをできるだけシンプルにする必要がありますが、シンプルにする必要はありません。」
ここには、LOCを低く抑えることの技術的な長所と短所、および意味のある高品質のソフトウェアメトリックであるかどうかに対処するための多くの回答があります。それはこの質問が何についてであるかではありません。それが何であるかは、特定のコーディングの経験則への素朴な独断的な順守を主張する管理にどのように対処するかです。
悲しいことに、人々が適切なコンテキストで使用され、実用的に適用されたときに優れたアドバイスであるものにラッチし、そのコンテキストからそれらを取り出して、最初から緩和するためにアドバイスが存在する問題を理解できないまま、それらを独断的に適用することはかなり一般的です。
LOCを低く抑えることに関するアドバイスの目的は、一度に多くのことを実行しようとするメソッドの作成を避け、「神のクラス」の作成を阻止することです。システム内の他のすべてのクラスが依存する直接の責任。短いコードのもう1つの利点は、コードが読みやすくなることですが、指摘したように、実際に読みやすさが低下し始めるところまでコードをやり過ぎることがあります。
LOC数が少ないことには明らかな利点があります（小さなメソッドは大きなメソッドよりも頭にフィットしやすく、コード内の事柄が少ないほど、失敗することが少なくなります）などもありますが、それはリターンを減少させる法則の影響も受けます。 150行メソッドを20行メソッドの数にリファクタリングすることは、10行メソッドを7行メソッドにリファクタリングするよりもはるかに大きなメリットです。
そのようなリファクタリングが、優れたソフトウェア設計（可読性など）の他の側面を犠牲にして行われると、それを行わないことを正当化できるポイントに到達します。コードの意味するコンテキストを与える変数を削除し、それらをそうでないリテラルで置き換えることは、非常に悪いことです。良いコードにはリテラルがほとんどありません。ただし、これらの変数（および名前付き定数）は、プログラムに直接寄与しないコード行であるため、LOCがある種の神として崇拝されている場合、そのような明確化行は、迅速な勝利のために剪定されるのに非常に危険です。管理からの誤った賞賛。
私はあなたがこれを実現するのに十分賢いと信じています、実際それはあなたの元の質問のほとんどの推力です。問題は、コード削減が適切な場合の理解ではなく、適切でない場合、通常は無差別に合理的な方法を適用する際の独断性です。
時間をかけて管理職とチャットし、自分の立場と、要求されていることがコードを助けるのではなく害を及ぼす理由について説明することをお勧めします。対立しないように努めるが、そのような議論の間は合理的で冷静さを保つように努めなさい。プログラミングは実用的な活動であることを経営陣が理解することが重要です。ベストプラクティスのアドバイスは、実用的な方法で適用された場合にのみ役立ちます。ベストプラクティスは石に刻まれたものではなく、本に書かれており、矛盾する場合（短いコードと読み取り可能なコード）、どのベストプラクティスに従うかについての判断はプログラマーの責任です。うまくいけば、彼らはこのような意見に感謝する合理的な人々です。
また、LOCを不必要または不適切であると考えるように圧力をかけられている場合は、静かな生活のためにとにかく変更を加えるのは当然のことです。これに抵抗する必要があり、その決定を「所有」する必要があります。管理が合理的である状況では、ガイドラインを正確に遵守する必要はありませんが、そうでない状況を正当化できるはずです。
悲しいことに、人々は、特に彼らの決定とあなたに課した規則を疑問視するつつく順序を下げる人々に関しては、非合理的である可能性があります。彼らは合理的でないことを選択するかもしれません。あなたもそのために準備する必要があります。 LOCのベストプラクティスが他のベストプラクティスと直接競合するケースとそれが製品に悪影響を与える理由を示すことができ、個人的にほとんどまたはまったく関与していないコードベースの部分でそれを行うことができる場合（そうすることで彼らの仕事や監督された仕事に対する個人的な攻撃のようには思えない）そして、これはあなたの主張を強化するのに役立つかもしれない。繰り返しますが、冷静で合理的な方法で自分自身を正当化する準備をし、あなたがしている議論を「所有」できるようにする必要があります。
あなたの経営陣が合理的な人々であるならば、彼らはあなたがあなたの主張を裏付ける証拠を提供することができればあなたが言っていることがメリットがあることを認めなければなりません。
確かにSLOCの数が少ない機能を持つように努力すべきだと思います。
LOC（コードの行）が小さい場合、コードにどのように影響し、LOCが大きい場合、コードにどのように影響しますか？
理想的には、30行を理解するよりも、8行のコードを一目で理解する方が簡単なはずです。
8行で圧縮された30のLOCが理解しやすくなるという意味ではありません。
あなたは何をする正しい方法だと思いますか？.
通常、関数では、抽象化のレベル（「IOコードはここ」、「検証はここ」、「計算はここ」など）でグループ化しようとします。
次に、空白行で区切られたブロックに分割します。コードが約10行を超える場合は、各ブロックを異なる関数に抽出します（とにかく、2回以上表示されるコードについても同様です）。この方法でパフォーマンスを壊すことについての議論（不要な関数呼び出し）を聞いたことがありますが、実際にはこれによってパフォーマンスのボトルネックが発生することはありません。
とは言っても、この抽出を行った関数はありました。その後、関数は約40行（Cコード）でした。 Ifコードは可能な限りグループ化されているので、長い関数の問題は発生しません。
LOCよりも、クリーンで自動ドキュメント化されたコードに焦点を合わせることが重要だと思います。ただし、理由は言うまでもなく、コードが何をしているかを説明しているので、あなたの例はあまり好きではありません。たとえば、これ：
boolean sweet_sixteen =（年齢== 16）;
かなり冗長です。 「age == 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とは別であり、テストすることができ、簡単に理解できます。しかし、より重要なのは、コードを読んだ人は、コードがそのように記述された理由を理解できることです（「企業は、一部の人々のために大規模なパーティーを開きたい」）。
通常の場合、行数は問題とは見なされませんが、問題がある可能性があります。誰かが1000行のコードを含むクラスを表示する場合、クラスの実行または設計の方法に何らかの問題があるはずです。
あなたの例は、より多くのコード行が意味をなす場合を示しています。しかし、それはその例です。計画の欠如に線の数が付随する例を毎日目にします
コードの行が少ない=読みやすいコードだと思います
しかし、もちろん、行数を減らすためだけにコードを縮小/不明瞭化し始めるときには、いくつかの制限があります。
/** 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}
コードの一部を削除しても、アルゴリズムが想定どおりの動作をしている場合は、続行してください。コードを縮小しないでください。それを行うためのより良いツールがあります。
コードの行数が少ない==より読みやすいコードだとは思わない。ただし、理論とはかなり異なる現実は、行数の多いコードは、適切な設計なしに記述されることが多いということです。その結果、より少ない行数の要件により、一部のプログラマーは、可能であればより良い設計を思い付く場合があります。ひねりは、多くのプログラマーがそうではないということです、そして、要件は多くを助けません。
LOCは、実際の実装時よりもプロジェクトの開始時に有用な方法だと思います。 機能ポイントごとのLOC を知ることで、プロジェクトの作業量、およびプロジェクトの所要時間と最適な開発者数を見積もることができます。
また、デザインと言語の選択にも影響を与える可能性があります。関数ポイントを減らすか、LOC/FPが低い言語に切り替えると、プロジェクトの労力が減り、他のすべての条件は同じになります。
コード行自体はそれほど重要ではありません。それを見る一つの方法は、散文と比較することです。最初の認識は、コードと散文の両方の重要な特性（正しさを前提とする）は読みやすさです。可読性（および理解可能性）は、保守性や正確性などの他の特性に役立ちます。
関数を少数の行に収めることができる利点があります。ただし、段落のないテキストを使用すると、読みやすさが低下します。難しい概念、難しい（まれな）単語、複雑な表現方法を使用すると、一般的にアイデアを表現するために必要な単語の量が減りますが、同時にテキストの読解レベルは中等学校レベルから専門学校（散文の場合）。
一般に、コードに抽象化を追加してヘルパーなどを使用すると便利ですが、これらの抽象化は非常に多くなる可能性があります。また、複雑さがコードの別の部分に移動することも起こり得ます。専門家として、ジュニアプログラマー（または学生）が使用するフレームワーク/ライブラリーを設計しているときのように、これを行うのは良い考えです。しかし、後輩があなたのコードがどのように機能するかを理解できると期待しないでください、彼らが誤ってそれを使うのを非常に難しくします。
コードを書くときは、特にコードに空の行を追加しないようにしてください。それらは段落として機能し、関数のさまざまな部分を分離するのに役立ちます（たとえそれらがまだヘルパーに入れられるべきではない場合でも）。