ソースファイルの最後に空の行を含めることが推奨されるのはなぜですか？

一部のコードスタイルツールはこれを推奨しており、UNIXコマンドラインツールで空の行がないことに関する警告が表示されたことを覚えています。

空の行を追加する理由は何ですか？

テキストファイルのデータの最後の行が改行または改行/改行の組み合わせで終了していない場合、多くの古いツールは正しく動作しません。代わりに^ Z（eof）で終了しているため、その行は無視されます。

2つのテキストファイルを連結しようとする場合、最初のテキストファイルが改行文字で終わっていると非常に便利です。

テキストエディタでファイルの最後に移動すると、カーソル位置が適切になるという事実は別として。

ファイルの最後に改行があると、ファイルが切り捨てられていないことを簡単に確認できます。

末尾のコンマがリストで許可されている理由と同じ理由でファイルに追加すると、より明確なdiffの引数を作成することもできます。

以下は、リンクされたリソースからコピーされます（および少しトリミングされます）。

変化：

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マーカーまで実際に読み取られるため、ランタイムライブラリの入力から読み取る関数は、それ以上読み取りを停止するタイミングを認識します。Appendモードでストリームを開くと、closeが明示的に呼び出されてその時点でEOFマーカーが挿入されるまで、EOFマーカーがワイプされて書き出されます。

古いツールは、EOFマーカーが後に続く空の行を予期していました。現在、ツールは空の行を処理して無視できます。

また、ファイルを変更してファイルの終わりにコードを追加すると、diff（少なくとも標準構成ではgit diff）は最後の行を変更したことを示しますが、実際に行った唯一のことは改行記号を追加したことです。そのため、CVSレポートは不便になります。

一部の言語では、入力ファイルを入力行で定義しています。各入力行は、改行で終了する一連の文字です。文法がそのように定義されている場合は、ファイルの最後の有効な行も改行で終了する必要があります。

これは、テキストファイルの定義によるものです。UNIX環境で新しいテキストファイルを作成すると、そのファイルの内容は改行文字 '\ n'になります。

これがないと、ファイルは実際にはテキストファイルとして識別されません。ここで、このテキストファイルにコードを追加したら、テキストファイル自体を定義するこの最初の新しい行は削除しません。