一部のコードスタイルツールはこれを推奨しており、空の行が欠落していることを警告するUNIXコマンドラインツールがいくつか見られたことを覚えています。
余分な空の行がある理由は何ですか?
一部のコードスタイルツールはこれを推奨しており、空の行が欠落していることを警告するUNIXコマンドラインツールがいくつか見られたことを覚えています。
余分な空の行がある理由は何ですか?
テキストファイルのデータの最後の行が改行またはキャリッジリターン/新しい行の組み合わせで終了していない場合、多くの古いツールは誤動作します。代わりに^Z(eof)で終了するため、その行は無視されます。
2つのテキストファイルを連結しようとすると、最初のファイルが改行文字で終わっていると、はるかに幸せになります。
テキストエディタでファイルの最後に移動すると、カーソル位置がより適切になるという事実は別として。
ファイルの最後に改行を入れると、ファイルが切り捨てられていないことを簡単に確認できます。
リストで末尾のコンマが許可されているのはなぜですか?と同じ理由でファイルに追加すると、よりクリーンな差分を求める引数を作成することもできます。
リンクされたリソースから以下がコピーされます(そして少しトリミングされます)。
変化:
s = [
'manny',
'jack',
]
に:
s = [
'manny',
'jack',
'roger',
]
差分の1行の変更のみが含まれます。
s = [
'manny',
'jack',
+ 'roger',
]
これは、末尾のコンマが省略された場合に、より紛らわしい複数行の差分を打ち負かします。
s = [
'manny',
- 'jack'
+ 'jack',
+ 'roger'
]
ファイルの終わりに空の行が表示されるので、入力ストリームからの標準の読み取りで読み取りを終了するタイミングがわかります。通常、EOFを返し、最後に到達したことを示します。大多数の言語はEOFマーカーを処理できます。そのため、昔からDOSではEOFマーカーはF6キーまたはCtrl-Zでしたが、*nixシステムではCtrl-Dでした。
すべてではないにしても、ほとんどの場合、実際にはEOFマーカーまで読み取られるため、ランタイムライブラリの入力からの読み取り機能は、それ以上の読み取りをいつ停止するかを認識します。追加モードでストリームを開くと、EOFマーカーがワイプされ、その時点でEOFマーカーが挿入されるcloseが明示的に呼び出されるまで、それを超えて書き込まれます。
古いツールでは、空の行の後にEOFマーカーが続くことを期待していました。現在、ツールは空の行を処理して無視することができます。
また、ファイルを変更し、ファイルの最後にコードを追加すると、diff(標準の構成では少なくともgit diff)は最後の行を変更したことを示しますが、実際に行ったのは改行記号を追加したことだけです。そのため、cvsレポートは使い勝手が悪くなります。
質問、および既存の回答のほとんどは、誤解に基づいているようです。
一般に「改行」(\n
CではU + 000A LINE FEED)と呼ばれるASCII制御文字は、(Unixスタイルの)テキストファイルの新しい行を開始しません。テキストファイルの現在の行を終了します。テキストファイルの最後の文字がU+000Aの場合、U + 000AとファイルシステムのEOFマーカーの「間に」空行はありません(ただし、これは実装されています)。逆に、(空でない)テキストファイルの最後の文字がU + 000Aでない場合、ファイルの最後の行は終了していません。「不完全」であると言われます。
これは、いくつかの例でおそらくより明確になります。
このファイルには、2行の完全なテキストが含まれています。3番目の空の行は含まれていません。
$ printf 'first\nsecond\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a first.second.
このファイルには、3番目の空の行が含まれています。
$ printf 'first\nsecond\n\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a0a first.second..
また、このファイルには、完全な1行と、2番目の不完全な行のみが含まれています。
$ printf 'first\nsecond' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 first.second
不完全な最終行が必要な場合があります。たとえば、?>
PHPスクリプトの最終行とEOFの間に改行があると、レンダリングされたHTMLの不適切な場所に余分な空白が出力される可能性があります(具体的な例にリンクします)。しかし、今朝、私はそれを見つけることができませんでした)。したがって、優れたテキストエディタは、UIで上記の3つのケースすべてを明確に区別します。
ただし、古いテキスト処理ツールは、不完全な最終行を誤って処理することがよくあります。たとえば、の一部の実装でwc
は、不完全な最終行を行としてカウントしません。また、の一部の実装でvi
は、必要かどうかに関係なく、末尾が1つでないファイルに改行をサイレントに追加します。したがって、不完全な最終行は、それらを必要とする特定の理由がある場合にのみ使用する必要があります。
(注:私が知る限り、今言ったことはすべてDOSスタイルのテキストファイルにも当てはまります。DOSスタイルのテキストファイルでは、U + 000Aだけでなく、2バイトの制御シーケンスU + 000D U+000Aが行の終わりに使用されます。 )。
一部の言語では、入力ファイルを入力行で定義します。各入力行は、キャリッジリターンで終了する一連の文字です。それらの文法がそのように定義されている場合、ファイルの最後の有効な行もキャリッジリターンで終了する必要があります。
これは、テキストファイルが何であるかを定義しているためです。UNIX環境で新しいテキストファイルを作成すると、そのファイルの内容は改行文字'\n'になります。
これがないと、ファイルは実際にはテキストファイルとして識別されません。このテキストファイルにコードを追加したら、テキストファイル自体を定義するこの最初の新しい行を削除しないようにします。