余計な空白は悪いことですか？
友人や同僚から、多くの場合、空白を多く使用する方法をよく言われます。私は少しtoo多くの空白を使用していると思います。私は多くの場合、ほぼすべての行と空白の大きなブロックの後に改行を追加します。多くの場合、3行または4行です。これは、自分が書いた内容を確認し、後で振り返るときに自分が書いた内容を理解するのに役立つためです。見た目もすっきりしていると思います。
これには2つの問題がありますが、1）ソースファイルのファイルサイズが大きくなる可能性があります。2行または3行ごとに改行するだけでも、長いファイルに追加される可能性があります。私は良いコンパイラーがすべての空白を最適化することを知っています（実際にはわかりません、LLVM/Clangがこれを行うと思います）が、ソースファイルはまだ大きいです。
そして、2）一部の人々は、コードを装飾しているように思わせて、長く見させ、「大きく」して、実際よりも多くの作業をしていると他の人に思わせることができます（3000行と6000行を比較すると、3000は改行）。ちなみに私はそうしていません。技術的な観点および/または専門的な観点から、余計な空白を使用することは悪いことですか？
これを行わないことを強く検討すべき理由は2つあります。
関連するすべての部分を一度に表示できない場合、コードを理解するのがはるかに難しくなります。ほとんどの行の間に空白行を挿入すると、表示できるコードの量が半分になります。
グループプロジェクトでは、他の人のコードとの一貫性が重要です。それが一貫している限り、プロジェクトがどの特定の慣習に従うかはあまり重要ではありません。大規模なシステムを理解するのは十分に困難です。各部分に異なるインデントスキーム、命名規則、およびイディオムがある場合は、さらに難しくなります。
空白は、テキストのセクションを分割してさまざまな部分をより明確にし、「これはブロックです。そのコンテキストで見てください」と目立たせるのに役立ちます。
水平方向の空白はインデントとスコープに使用され、ヒントも表示されます。垂直方向の余白を多く入れすぎると、インデントを追跡する機能が失われます。 {}がない言語では、これはコードのコンテキストにとって悲惨な結果になる可能性があります。
そのコンテキストは非常に重要です。画面に何かが表示されない場合は、すぐにスキャンして元に戻すことはできません。スクロールする必要があります。これは、あなたが見ていたコードを失い、手をマウスに動かす必要があることを意味します。これらのものは、時間と精神的なエネルギーのいくらかの支出を必要とします。それは少量の精神的エネルギーでありえますが、それでもいくらかの不必要な支出です。
実際にこれを見て、コードを取得しましょう。これは _ header_value_parser.py からのものです
テキストはそれほど重要ではありませんが、画面上ではかなり少ないことに注意してください。ページで完全なメソッドを取得することもできません。そして、いくつかのブロックがどこに並ぶかについての質問があります-目は遠くまで物事を保ちながらあまり移動しません（それは フルサイズ 画像でより明確になります-176行目が整列します） 135または133の範囲で？）.
チェックインする行の数についてではありません（コードチェックインメトリックをカウントする1つが、代わりに コードのソース行 を使用しており、空白が割引され、コメント行も割引される場合があります）。それは目と心の簡単な交換距離に物事を保つことについてです。
余計な空白は悪いことですか？
明らかに：はい。あなたが言うなら、それは多すぎる、そしてそれは何か臭いが起こっているという兆候です。
私は多くの場合、ほぼすべての行と空白の大きなブロックの後に改行を追加します。多くの場合、3行または4行です。これは、自分が書いた内容を確認し、後で振り返るときに自分が書いた内容を理解するのに役立つためです。見た目もすっきりしていると思います。
あなたの問題は空白ではなく、あなたの問題はclean code以上です：クリーンなコードの欠如。
クリーンなコードが教える1つのレッスンは、大きなコードブロックを小さなブロックに分解することです。きっと、あなたがwhitespacheで包むすべてのブロックはブロックであり、細かく切り刻んで便利な小片にすることができます。
パラノイアで試してください：10行を超えるすべての関数は、小さなチャンクに分割する必要があります。また、OOを記述している場合：200行を超えるすべてのクラスは大きすぎます。
もちろん10/200行は任意の数ですが、しばらくこのルールに従うと、次のような効果に気づくでしょう。 、そして最終的には保守可能です。
これには2つの問題がありますが、1）ソースファイルのファイルサイズが大きくなる可能性があります。2行または3行ごとに改行するだけでも、長いファイルに追加される可能性があります。私は良いコンパイラーがすべての空白を最適化することを知っています（実際にはわかりません、LLVM/Clangがこれを行うと思います）が、ソースファイルはまだ大きいです。
なぜファイルサイズを気にするのですか？私たちは80年代に住んでいるわけではなく、すべてをテープに保存しています。私たちはBig Dataの時代です。それは間違った懸念です。また、ブロックを読み取り可能なチャンクに分割すると、ファイル数とサイズが増加します。しかし、心配しないでください。
そして、2）一部の人々は、コードを装飾しているように思わせて、長く見させ、「大きく」して、実際よりも多くの作業をしていると他の人に思わせることができます（3000行と6000行を比較すると、3000は改行）。ちなみに私はそうしていません。技術的な観点および/または専門的な観点から、余計な空白を使用することは悪いことですか？
それも間違った懸念です。 LoCまたは出力のバイトサイズで測定されている場合は、ジョブを終了します。コードは量ではなく質で測定されるべきです。
使用しているプログラミング言語には Google Style Guides をお勧めします。私はこれらのルールを順守し、通常、それらはきれいに見えるコードにつながります。自分で追加したものがあります（関数の間に2行の空白行など）が、全体的に本当に Googleスタイルガイド が好きです。
更新：
さまざまなスタイルガイドは言語ごとに少し異なります。これらは、その言語での作業にすべての時間を費やしているさまざまなエンジニアによってまとめられているため、書き留めたものが、見栄えの良いコードにつながると信じているものです。概して、経験則は、コードグループを区別するために空白行のみを使用することです。複数の連続する空白行が推奨されることはほとんどありません。これらのガイドからの抜粋をいくつか示します。
Java
単一の空白行が表示されます。
- Betweenクラスの連続するメンバー（または初期化子）：フィールド、コンストラクター、メソッド、ネストされたクラス、静的初期化子、インスタンス初期化子。
- 例外：2つの連続するフィールド間の空白行（フィールド間に他のコードがない）はオプションです。このような空白行は、フィールドの論理グループを作成するために必要に応じて使用されます。
- メソッド本体内で、必要に応じてステートメントの論理グループを作成します。
- オプションでクラスの最初のメンバーの前または最後のメンバーの後に（推奨も推奨もされません）。
- このドキュメントの他のセクションで必要な場合（セクション3.3、Importステートメントなど）。
複数の連続した空白行が許可されますが、必須ではありません（または推奨されません）。
Python
関数またはクラスの定義であっても、トップレベルの定義の間には2行の空白行があります。メソッド定義の間、およびクラス行と最初のメソッドの間の1つの空白行。関数またはメソッド内で適切と判断する場合は、1行の空白行を使用してください。
C++
垂直方向の空白の使用を最小限に抑えます。
これは原則よりも原則です。必要がない場合は空白行を使用しないでください。特に、関数の間に1行または2行以上の空白行を入れないでください。空白行で関数を開始しないでください。空白行で関数を終了しないでください。関数内で空白行を使用することで区別してください。
基本的な原則は次のとおりです。1つの画面に収まるコードが多いほど、プログラムの制御フローを理解しやすくなります。もちろん、読みやすさは、コードが密集しすぎたり、広がりすぎたりする可能性があるため、慎重に判断してください。ただし、一般的には、垂直方向の空白の使用を最小限に抑えます。
空白行が役立つ可能性がある場合に役立つ経験則：
- 関数の最初または最後の空白行が読みやすくなることはほとんどありません。
- If-elseブロックのチェーン内の空白行は読みやすさを改善するのに役立ちます
Objective-C
@ interface、@ implementation、@ endの前後の空白行はオプションです。 @interfaceがインスタンス変数を宣言している場合、右中括弧（}）の後に空白行が来るはずです。
少数のプライベートメソッドやブリッジクラスを宣言する場合など、インターフェイスまたは実装が非常に短い場合を除き、通常、空白行を追加すると読みやすくなります。
ここでは垂直空白に関する情報のみを記載していますが、一部のガイドには水平空白に関する情報と、より多くの書式設定情報（コメント、ブロック、インデントなど）もあります。
そしてプロジェクトはオープンソースなので、提案があれば、プロジェクトオーナーの1人にメールを送ることができます。
それは、余りにも多くのスペースが何を意味するかによります。私にとって、コードの読みやすさを向上させるためにスペースを使用することが重要かつ原始的です。関数内のいくつかのブロックを分離するために1行を空けて使用し、関数とクラスの間の空きスペースを確保します。また、言語が少ないアラインシンボルもクールです。
sub my_function {
my $arg = @_;
my $a = 42;
my $b = 50;
my $sum = $a + $b;
my $map = {
key => 'value',
second => 'second value'
}
if ( $sum > $ arg ) {
return $sum
}
return;
}
私の好きな小さな例ですが、もしあなたが私のラインスペースを使いすぎたら、ハバハは良くありません。たとえば、最後のリターンと条件付き構造の間に5行の空きがあるので、私にはそれは悪い考えです。
他の良い答えに加えて、ツールの問題もあります。優れたテキストエディタは、開始と終了の角かっこを一致させる機能（強調表示など）を提供します。しかし、geditのように、遠く離れていると実行できないものもあります。もちろん、それは長いメソッドも避けるべきであることを意味しますが、垂直方向の余白が多すぎることも害を及ぼす可能性があります。
空白行は、論理ブロック（テキスト内の段落など）を区切るために使用される場合、プログラムを読みやすくするのに役立ちます。すべてが分離されている場合、それは何もなかったかのようです。
コード内の空白は強調を作成するために使用できます。コードブロックの前後の空白行は、ブロック内のコードが周囲のコードよりもそれ自体に少し近いことを示すために使用できます。コードのすべての行の間に空白行を挿入すると、この強調方法を使用できなくなるため、この強調が必要な箇所に複数の空白行を使用します。強調の点では何も得られず、空白行がたくさん得られただけです。
あなたはあなたのコードがよりきれいに見えると思います。汚れている状態の面白い点は、汚れていると見なされるのは実際には何もないことです。実際にきれいであるのではなく、きれいに見えるとは、単に汚れが見えないことを意味します。だからはい、空白行が多すぎると間違いなくコードがきれいに見えます。これにより、同時に表示できるコードの量が制限されるため、同時に不明瞭なコードの量も制限されます。しかし、単純にきれいに見えるコードは、あなたや他の誰かがそれを書いたり維持したりするのに役立つことはありません。逆に、汚れが見えることは、汚れに対処するための前提条件です。
スペースを過度に使用するというはるかに広く行われている慣行について、やや似たような議論があります。次のようなコードを見てください。
while ( x > y || foo != bar || ! ( a in b ) ) {
デフォルトのスペースのないスタイルを使用することで、いくつかのスペースを使用して、条件の3つの異なる部分を強調できます。
while(x>y || foo!=bar || !(a in b)){
空白を減らすのに慣れない場合は、大きなフォントやより多くの行間を使用するようにエディターを構成することを検討してください。少なくとも同僚は問題なくコードを読むことができ、時間をかけて徐々に変更できるようになる場合があります。通常の設定。
関数に大量の空白を追加すると、便利なブロックに分割される場合がありますが、有用な情報は含まれていません。
セクション間に複数の空白行を追加する必要があると感じた場合は、コメントを追加して、コードの次のビットが何をするかを説明する必要があります。
さらに、Thomas Junkが指摘したように、長すぎる関数は、より小さく管理しやすい関数に分割する方が適切です。
余白が多すぎる可能性があります-通常、ブロックと最後の中括弧の間に空白行を表示するのは面倒です。例：
if (x)
{
// do something
// do more
}
それは私をとても困らせます。しかし、私は関数間の複数の空白行が好きです-関数内の論理ブロックには1行で十分なので、2を指定すると各関数がそれだけ目立つようになります。
関数内では、関数内の論理ブロックが関数自体のように見えるほどスペースを空けたくありません。読者がこれらのブロックを一緒にグループ化する能力を混乱させ始める余分な白を導入することなく、テキストの大きなブロックを分割して読みやすいように（本の段落のように）しようとしています。
だから：あなたのためのクイックスタンダード：1。正しくインデント。 2.必要に応じて、ブロック間の単一の空白行3.関数間の複数の空白行。 4. nowhereそれ以外。
それに固執すれば、あなたは幸せな同僚と整頓されたコードを手に入れるでしょう。
それは間違いなく他の人が言及したさまざまな要因に依存します。
より多くの空白を必要とする状況がいくつかあります。私は好むかもしれません
class Thing
def method1
stuff
end
def method2
stuff
end
end
に
class Thing
def method1
stuff
end
def method2
stuff
end
end
これらのメソッドが長くなる場合は、それらの間にwhtespace行があると便利です。
したがって、コードの一般的なガイドラインとして、空白行の％に対して、10％から30％の間の数値を探します。それよりも少なく、長いアルゴリズムがあり、それよりも多く、上下にスクロールして、コンテキストと視覚的な「一緒に見る」グループ化が失われる可能性があります。
しかし、それは言った...
一部の用途では、「すべてを1つの画面に表示する」ことが非常に役立ちます。
私の.bashrcファイルが3または4の「画面の価値」に達し、さらに多くを導いた場合の良い例：
- 同じ設定の複製
- 同じ設定の競合する使用
- 設定を忘れて
この場合、私はそれを「圧縮」するために多くの努力をしました。この場合、空白だけでなくif thenコンストラクトは1行に収まります。
test -f ~/.bash_aliases && . $_
小さなターミナルウィンドウでさえ、私が一度にすべてを見ることができる27行にそれを取得することができました。
最後に、あなたが言及する2つの問題-ファイルサイズとパディングの長さは、私が知っていて尊敬するプログラマが注意を払う要素ではありません-100GBは1億バイトであることを覚えておいてください。追加の行スペースは、行スペースの好みと見なされます。コードが実際に機能した場合、これは通常は比較的小さな問題ですが、チームでは合意すべきものです。
空白に関しては、ファイルサイズとコンパイルのパフォーマンスは問題にならず、空白はコンパイラの出力に影響を与えません。
すべては読みやすさですが、特定のサンプルの読みやすさは読者によって異なります。
他の回答で述べたように、垂直方向の空白が多すぎると、コードの一部がコンテキストから外れ、適切な理解にそのコンテキストが必要な場合に理解が損なわれる可能性があります。通常、何も2行以上の空白行で区切ることは決してありません。コンテキストを犠牲にすることなく、少しのコードを開始するのに十分です。関数の間に4つの空白行を要求する開発者と協力しました。彼はそれが読みやすさのために役立つと感じました、私は過度であると感じました、読みやすさには何も貢献せず、それはナビゲーションを妨げました。
チームで作業している場合は、スタイルガイドを用意し、それに従って作業する必要があります（自家製のものか、より広く配布されているものか）。おそらくそれはそのコードで作業しなければならない読者の大多数を収容するでしょう。