web-dev-qa-db-ja.com

間隔の使用は、長いメソッドコードのにおいと実質的に同等ですか？

長いメソッドに関連する一般的なコードの臭いがあり、最も一般的な答えは、メソッドは本当に小さく、1行あたり50行（または20行）未満である必要があるということです。読みやすさの向上、繰り返しコードの削減などが理由です。しかし、これがステートメントレベルなのか、ファイル行レベルなのか疑問に思いました。

たとえば、呼び出されているメソッドがあり、渡された多くのパラメーター（この例ではLPLの匂いを無視）があり、IDEの一般的な編集ウィンドウサイズの幅にまたがるほど多すぎるとしましょう。

method(A, B, C, D, ...);

[〜＃〜] edit [〜＃〜]文字付きパラメーターが型付き変数であると想定し、省略記号はその他のパラメーターを示します。

しかし、誰かがこのようなメソッド呼び出しを書くかもしれません

method(
A,
B,
C,
...);

これは複数の行にまたがっていますが、私の個人的な意見では、横にスクロールするよりも下にスクロールして読む方がはるかに簡単です。マウスを左右にスクロールすると、多くの場合（左から右）スクロールバーをマウスで選択する必要があるため、マウスでの操作も異なります（ボタンをプログラムしてこれを行うようにプログラムでき、一部のマウスにはジョイスティックが組み込まれていますが、ビジネスでは一般的ではありません）。

これはSQLクエリに関連していると思います。例えば

SELECT 
 A.A
,A.B
,B.C
,B.D
FROM 
table A
LEFT JOIN
table B
ON
A.E = B.E
AND 
A.F = B.F
WHERE 
A.A IS NOT NULL
AND 
B.C > 50

さて、このシナリオでは、私がテストしているときに、where句やchange論理演算子をコメントアウトするのは非常に簡単です。すべてを1行にして再入力する必要がある場合は、削除を実行する代わりにコメントアウトしてください。

長い行のメソッドの匂いが実際に何を意味するのか、多くのステートメントの観点から見た長い行なのか、ファイルあたりの行数の観点から長い行なのか、疑問に思っていたのでしょうか。

designcoding-stylesqlsql-servercode-smell
4
Jake

間隔の使用は、長いメソッドコードのにおいと実質的に同等ですか？

番号。

行番号を考慮して空白を削除しないでください。どちらかといえば、これは行カウントが良い品質の指標ではないことを示しています。

メソッドと関数は短くする必要があります。非常に短い。それらをより小さなものに分解できる場合は、それだけを検討する価値があります。

しかし、行カウントは本当にばかげています。特に空白を無視する言語では。プログラム全体を1行で定義できます。それは良いことにはなりません。

今個人的に私はこの例が非常に読みやすいと思います：

method(A, B, C, D);

私はこれがとても読みにくいと思います：

public String method(final String Alessandro , final String Bartholomew, final String Cleveland, final String Dashiell) { return ""; }

それらは同じ数のパラメーターを持っていますが、これはひどいです。読みやすくするために空白を追加する価値があります。

public String method(
        final String Alessandro, 
        final String Bartholomew, 
        final String Cleveland, 
        final String Dashiell
) {
    return "";
}

幅や長さを考慮して、名前を短くしないでください。できる限り最適な名前を​​使用して、コードをレイアウトするためのより良い方法を見つけてください。

しかし、私は見つけます

method(
A,
B,
C,
...);

無駄にスペースを無駄にする。少なくとも、いくつかのインデントを使用してください。

method(
    A,
    B,
    C
);

そのような短い名前と他の装飾がないので、これはまだばかげているようです。しかし、少なくともそれは構造を強調しています。これを行う正当な理由があれば、空白を否定することはできませんが、理由がわからない場合は迷惑です。

SELECT 
 A.A
,A.B
,B.C
,B.D
FROM 
table A
LEFT JOIN
table B
ON
A.E = B.E
AND 
A.F = B.F
WHERE 
A.A IS NOT NULL
AND 
B.C > 50

これは見にくいです。あなたがしたすべてはあなたのコメントスキームを許可することです。それはそれよりもはるかによく読むことはありません

SELECT A.A, A.B, B.C, B.D FROM table A LEFT JOIN table B ON A.E = B.E AND A.F = B.F WHERE A.A IS NOT NULL AND B.C > 50

それでも、他の考慮事項に柔軟に対応できます。キーワードとパラメータの間に視覚的な分離を追加できます

SELECT 
     A.A
    ,A.B
    ,B.C
    ,B.D

FROM 
    table A

LEFT JOIN 
    table B

ON 
    A.E = B.E

AND 
    A.F = B.F

WHERE 
    A.A IS NOT NULL

AND 
    B.C > 50

キーワード間の関係を強調できます

SELECT 
,A.A 
,A.B 
,B.C 
,B.D

    FROM 
    table A

    LEFT JOIN 
    table B 

        ON 
        A.E = B.E

        AND 
        A.F = B.F

    WHERE 
    A.A IS NOT NULL

        AND 
        B.C > 50

そして、コメントが行全体を占める必要がないことを覚えておく価値があるかもしれません：

SELECT A.A, /*A.B,*/ B.C, B.D
    FROM table A
    LEFT JOIN table B 
        ON A.E = B.E
        AND A.F = B.F
    WHERE A.A IS NOT NULL
        AND B.C > 50

空白は強力です。読みやすさに大きな影響を与えます。賢く使ってください。

線を数えることは、機能が短いはずであるということを学ぶことから得られる最悪の教訓です。空白や説明的な名前をすべて詰め込んだので、短くしないでください。あなたが住んでいるのはそれ自身の小さな名前の付いた機能であるすべてのものを与えたので、それらは短くあるべきです。

12
candied_orange

あなたのSQLの例はひどいです。それは物事を不必要に個々の行に分割し、大きな利益を提供することなく読みやすさを損ないます。

より良い配置は、次のように、主要なキーワードを改行し、賢明なインデントを提供することです：

SELECT A.A, A.B, B.C, B.D
  FROM table A
  LEFT JOIN table B 
    ON A.E = B.E
    AND A.F = B.F
  WHERE A.A IS NOT NULL
    AND B.C > 50

コメントアウトやテスト能力を損なうことはありません。

長いメソッド呼び出しを読みやすくするためのより良い方法があります。例えば：

var a = [long expression];
var b = [another long expression];
var c = ...

method(a, b, c, d, ...);
6
Robert Harvey