空白については、中括弧の配置について既にいくつかの意見があります。

私自身は、「論理的」なグループに属するものを分離するために、コードに空白行を振りかける傾向があり、できれば次の人が作成したコードを読みやすくすることを願っています。

実際、私は書くようにコードを構造化すると言います。数行（10行よりも短い）より長くない段落を作成し、各段落を自己完結させようとします。

例えば：

• クラスでは、一緒に行くメソッドをグループ化し、それらを次のグループから空白行で分けます。
• コメントを書く必要がある場合は、通常、コメントの前に空白行を入れます
• メソッドでは、プロセスのステップごとに1つの段落を作成します

全体として、私はめったに4/5以上の行が一緒にクラスター化されることはなく、非常にスパースなコードを意味します。

私は実際にコードを構造化するためにそれを使用しているので（実際にインデントを使用しているので）、この空白すべてを無駄とは考えていません。

例えば：

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

2つのステートメントには明確な明確な目的があるため、明確にするために分離する必要があると思います。

それでは、実際にコードで空白行を使用する（または使用しない）方法は？

常に

空白は、読み取り可能なコードをきれいにするために重要です。空白行（または2行）は、コードの論理ブロックを視覚的に分離するのに役立ちます。

たとえば、レイアウトとスタイルに関するSteve McConnellのCode Complete第2版の章から：

被験者は、プログラムにインデントがまったくない場合よりも、プログラムに2〜4スペースのインデントスキームがある場合の理解度テストで20〜30％高いスコアを獲得しました。同じ研究では、プログラムの論理構造を強調したり強調したりしないことが重要であることがわかりました。最も低い理解度スコアは、インデントされていないプログラムで達成されました。2番目に低いものは、6スペースのインデントを使用したプログラムで達成されました。この研究では、2〜4スペースのインデントが最適であると結論付けました。興味深いことに、実験の多くの被験者は、スコアが低くても、6スペースのインデントは小さいインデントよりも使いやすいと感じました。これはおそらく、6つのスペースのインデントが快適に見えるためです。しかし、どれだけきれいに見えても、6スペースのインデントは読みにくくなります。これは、審美的な魅力と読みやすさの衝突の例です。

はい、わかりやすくします。

この答えでやったように。

私はそうしますが、

(This line intentionally left blank.)

ライン上

はい、しかし私はそれを悪用しません。

メソッド内のすべてのコード行が空白行で区切られているコードを見てきましたが、論理的な分離が発生する場所では2つの空白行が使用されます。それは私の意見ではそれをさらに読みにくくしています。また、次のような狂気の整列を行うために使用される空白も見ました。

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

水平方向の空白の同じ誤用は、垂直方向の空白にも適用できます。他のツールと同様に、賢く使用してください。

この方法でコードを書くことで多くの批判を受けます。なぜこのようにしないのか理解できません。

長い期間を経てプロジェクトに戻ったときの読みやすさはとても重要です。「次の人があなたの場所を知っているサイコパスなら、常にコードを書いてください」という言葉を聞きました。

私はいつもソフトウェアを書くわけではありませんが、書くときは明確にするために空白行を使います。

私はコードをできる限り明確にすることを求めていますが、そのためには空白がしばしば有用なツールです。しかし、リファクタリングを忘れないでください：

• クラスでは、一緒に行くメソッドをグループ化し、それらを次のグループから空白行で分けます。

関連するメンバーが複数いるため、それらは新しいクラスの候補です。

• コメントを書く必要がある場合は、通常、コメントの前に空白行を入れます

コメントが必要なほどコードが不明確な場合は、コメントを必要としないコードを明確にするためにリファクタリングできるかどうかを尋ねます。

• メソッドでは、プロセスのステップごとに1つの段落を作成します

「段落」ごとに1つのメソッドを作成してみませんか？

クラスに多数のメソッドが存在する場合は、新しいクラスの抽出に関する上記のメモを参照してください。

はい。ファイルを視覚的にスキャンしやすくなります。特に、コメントの行を明確にします。

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

私は空白行を控えめに一貫して使用し、一貫して控えめに使用するよりも重要です。しかしながら：

• コードの各行が次の行と空白行で区切られている場合、空白行が多すぎます。
• 空白行がどこに配置されているかをすぐに認識できる韻も理由もない場合、それらは注意散漫であり、通常はそれらが多すぎます。
• 関数が大きすぎて多くの空白行が必要な場合、大きすぎます。
• コードのブロックがその前後に複数の空白行を必要とする場合、何か重大な迷惑があります。
• 関数間に3行以上の空白行がある場合、おそらく余りにも多くの空白行があります。

そのほとんどは恐ろしく物議をかもしていません。続くものがあります。行末に開き中かっこを使用したK＆R表記法の多くは、気のめいるほど空白行が続くことに注意してください。私は個人的に行末のブレースを嫌い、ブレースが記法の意味をなさない（IMNSHO）後に空白行と混合する。次の行に開き中括弧を単独で置くと、ほとんど空白行があります（そして、IMNSHO、より読みやすいコード）。行末でK＆Rブレースを使用する必要がある場合は、余分な空白行で垂直方向のスペースを無駄にしないでください。

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

最も読みやすく、驚くことの少ないものを書いてください。

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

この関数は12行のドキュメントコメントを必要としません。

実際、コメントは必要ありません。

または空白行。

彼らはその本質を損なうでしょう。

関数内？まれに

明確な別のブロックがある場合は、新しい関数にリファクタリングしています。少数の場合は価値がありません。

私にとって、関数内の空白行は最も間違った「ベストプラクティス」の1つです。

しばしば

同様に処理されるコードの論理ブロックに使用します。別のステップを実行していることを示すコメントを追加したら、メソッドを抽出します。

良い空白

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

悪い空白

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

対

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

対

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

空白を使用するだけでなく、わかりやすくするために中括弧を使用します。

これらが機能である可能性があると言うために使用する中括弧。

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

かつては、コード全体に空行をふりかけていました。今日、私はもっと控えめになる傾向があります。これはSteve Yeggeがここで話していたことの一部だと思う：

これまでに描いたシーンが、コードを見て、すぐにそれを嫌う理由を理解するのに役立つことを願っています。あなたがn00bなら、経験豊富なコードを見て、現代のソフトウェア工学の本質を一度も学んだことのない誰かによって書かれた、理解できない、規律のないがらくたであると言うでしょう。ベテランの方は、n00bコードを見て、インターンが1晩の大量飲酒で書いた可能性のある、過度にコメントされた装飾的な綿毛だと言うでしょう。

固着点は耐圧縮性です。キャリアを通じてコードを書くとき、特にコードが非常に異なる言語や問題ドメインにまたがっている場合、コード圧縮に対する許容度が高まります。巨大なテキストのある子供向けの本を読むことから、小さなテキストと大きな単語のあるますます複雑な小説へと進むことと違いはありません。

...

圧縮に対する耐性が高いプログラマーは、実際には画面いっぱいのストーリーテリングによって妨げられます。どうして？コードベースを理解するためには、できるだけ多くを頭の中に詰め込める必要があるからです。複雑なアルゴリズムの場合、ベテランプログラマーは画面上にすべてを表示することを望みます。つまり、空白行とインラインコメント（特に、コードの実行を単純に繰り返すコメント）の数を減らします。これは、n00bプログラマーが望むものとは正反対です。n00bsは一度に1つのステートメントまたは式に集中し、その周りのすべてのコードをビューの外に移動して、集中できるようにし、大声で叫ぶことを望んでいます。

私は基本的に彼に同意します。コードを圧縮し、スペースを取りすぎないようにすることで、1つの画面でできるだけ多くのコードを取得できるようにすることをお勧めします。それは、決して空白行を使用してはならないということではありません。作成しようとしているグループ化が読みやすさを大幅に向上させない限り、それは良いことよりも害を及ぼすと思うだけです。

名誉教授は2つの素晴らしいアドバイスを与えました

1. 空白は無料です
2. 用紙の前面から突き出ているステープルは使用しないでください。使用すると失敗します。

私の経験則は次のとおりです。

1. 昨日書いたコードの読み取りに問題がある場合は、おそらく1つまたは3つのメソッドを抽出する必要があります。

2. クラス定義が長すぎて読みにくい場合は、おそらくモジュール/インターフェイス/オブジェクトを抽出する必要があります。

3. メソッド定義：行を追加

4. モジュール/クラス定義：2行追加

空白は、段落と同じように考えるのが好きです。1つのアイデアに寄与する行をグループ化します。

新しいアイデアまたは同じアイデアの新しいファセットを開始する場合、このように新しい段落を開始します。

命令型コードでは、1つのまとまったタスクを実行するタスクをグループ化します。宣言型コードでは、アイデアの1つのまとまりのあるステートメントを記述するコードをグループ化します。

英語でそれを行うのに明らかに問題はありません（一部の人はパラグラフで恐ろしいです）ので、少し練習すれば、同じスキルをコードに適用してもまったく伸びないはずです。

私の意見では、空白行は必須です。それらを使用して、コードの異なる論理ブロックを分離します。コードを読み取り可能にします。読み取り可能なコードは良いコードです;）

私の理想的なコードは、各論理ブロックが空白行と主要なロジックを持つ各ブロックの上部のコメントで区切られていることです。

もちろん、どこにでも複数の空白行を追加することでそれをやり過ぎた場合、非常にいらいらします：

関数/メソッド内の空白のみを使用して、宣言とコードを分離します。

いくつかのロジックを実装するコードのサブブロックを分離するためにいくつかの行が必要であると感じる場合、それらは別の関数/プライベートメソッド内にあるべきです。オーバーヘッドが大きくなりすぎないようにするのは、コンパイラ次第です。

通常、peusdo-codeで：

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

役に立たない空白が表示された場合、私は通常うんざりしています。

ホワイトスペースは非常に貴重です。

E = MC ^2のような複雑なコードを書くオタクは、プログラミングスキルを披露するのに優れています。

6か月先に進みましょう。午前2時で、6か月間見られなかったシステムがE = MC ^2の行で壊れています。これはデバッグするのがほとんど不可能です...誰もがおかしくなります。

コードが次のようになっているとします...

See Dick
See Jane
See Dick and Jan

午前2時でコードが壊れている場合。一目で、3行目は

See Dick and Jane

問題が解決しました。

ボトムライン...空白を使用します。

他の多くの人が述べているように、空白行はコードを読みやすくします。ただし、この標準を強制する言語がいくつかあります。私が頭の中で考えることができるのは（空白行ではなく適切なインデント）Pythonです。

私は同意します、私は空白を同じように使います。ただし、メソッドを余りにも多くの部分に分割するために空白を使用している場合は、そのコードを複数のメソッドにリファクタリングする必要があるかもしれません。メソッド内の論理セクションが多すぎると、メソッドのテストが難しくなることを示す場合があります。

コードを論理ユニットに分離するために使用します。空白行を使用していないコードサンプルはほとんど見ていません。もちろん、難読化は例外です。

サイコパスの答えは最高ですが、私はそれを次の人がばかであると仮定し、彼らはあなたがそうであると仮定し、あなたは彼らが間違っていることを証明したいと思うでしょう。

読みやすさと同様に重要なのは、コメントの使用です。コメントブロックを使用して各関数またはサブルーチンを開き、クリアテキストで、それが何であるか、何をするか、引数とは何か、予想される結果は何か（エラー条件のリストを含む）を説明します。そして、それが何を意図し、そして/または何をするように設計されているのかについての質問はありません。達成することはさまざまですが、それはさらに先のことです。

私は、あまりにも多くのコーダーが、コードの「修復」を行うのは自分自身であると仮定するか、単に気にしないかのどちらかだと思います。

空白行が重要です。ただし、開きブレースの空白行全体を無駄にすると、画面全体に表示されるコードの量が減ります。する必要があります：

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

（ブレース '{'を 'for'と同じ行に配置し始めないでください...それはmeshuggahです）。

はい。読みやすくするため。書いていないコードに空白行を入れることさえあります。空白行を介した論理的なグループ分けがあると、コードを理解しやすくなります。たとえば、コードを「高速で読み取る」ことができます。

手紙を書くときと同じように、コードブロック間に空白行を使用する必要があります。

たとえば、関数間、またはループの終了時の関数内...

メンテナンスを行う必要がある場合、人々はクリーンなコードに感謝します;）

Microsoft StyleCopが推奨するホワイトスペースを使用します。読みやすさと一貫性のほかに、（小さなクラスサイズと共に）コードを適切にレイアウトすると、チーム内のさまざまな人が偶然同じ領域で作業しているときに、マージの管理がはるかに簡単になることがわかりました。

それが私の想像であるかどうかはわかりませんが、差分ツールは、それがきれいにレイアウトされているときにマージするときに、同等のコードが開始および終了する場所を認識するのにより良い仕事をするようです。うまくレイアウトされたコードは、マージする喜びです。わかりました、それは嘘でした-しかし、少なくとも痛みは管理可能なレベルに保たれています。

ファイル全体ではなく、決して空白行ではありません。それは、コードに中断がないと言うことではありません：

 code;
 //
 morecode;

空白行は、作業するコードのセクションを開くためのものです。エディターには、前/次の空白行に移動するためのいくつかのホットキーがあります。