これを推奨するコードスタイルツールもありますが、空の行がないことを警告するUNIXコマンドラインツールを見たことを覚えています。
余分な空行がある理由は何ですか?
テキストファイル内のデータの最後の行が改行または復帰/改行の組み合わせで終了していない場合、多くの古いツールは誤動作します。代わりに^ Z(eof)で終了するため、この行は無視されます。
2つのテキストファイルを連結しようとする場合、最初のファイルが改行文字で終わっていれば、より幸せになります。
テキストエディタでファイルの末尾に移動すると、カーソル位置がより適切になるという事実は別です。
ファイルの最後に改行があると、ファイルが切り捨てられていないことを簡単に確認できます。
以下は、リンクされたリソースからコピーされます(そして少しトリミングされます):
変化:
s = [
'manny',
'jack',
]
に:
s = [
'manny',
'jack',
'roger',
]
差分の1行の変更のみが含まれます。
s = [
'manny',
'jack',
+ 'roger',
]
これは、末尾のコンマが省略されたときに、より複雑な複数行のdiffに勝ります:
s = [
'manny',
- 'jack'
+ 'jack',
+ 'roger'
]
ファイルの終わりに空の行が表示されるため、入力ストリームからの標準読み取りはいつ読み取りを終了するかを認識し、通常はEOFを返し、終わりに到達したことを示します。 EOFマーカーを処理できます。そのため、DOSでは、EOFマーカーはF6キーまたはCtrl-Zでした。 * nixシステムでは、Ctrl-Dでした。
すべてではありませんが、ほとんどは実際にEOFマーカーまで読み取ります。これにより、ランタイムライブラリの入力からの読み取り機能は、読み取りをいつ停止するかを認識します。モードでは、EOFマーカーを消去し、それを過ぎて書き込みます。その時点でEOFマーカーを挿入するクローズが明示的に呼び出されるまで。
古いツールでは、空の行の後にEOFマーカーが必要でした。現在、ツールは空の行を処理して無視できます。
また、ファイルを変更し、ファイルの最後にコードを追加すると、diff(少なくとも標準構成ではgit diff)は最後の行を変更したことを示しますが、実際に行ったことは改行記号を追加します。したがって、cvsレポートの利便性は低下します。
一部の言語は、入力行の観点から入力ファイルを定義します。各入力行は、キャリッジリターンで終了する一連の文字です。文法がそのように定義されている場合、ファイルの最後の有効な行もキャリッジリターンで終了する必要があります。
テキストファイルとは何かを定義しているためです。 UNIX環境で新しいテキストファイルを作成すると、そのファイルの内容は 改行文字 '\ n'です
これがないと、ファイルは実際にはテキストファイルとして識別されません。このテキストファイルにコードを追加すると、 テキストファイル自体を定義する という最初の新しい行は削除されません。