Почему рекомендуется иметь пустую строку в конце исходного файла?

Некоторые инструменты стиля кода рекомендуют это, и я помню, как некоторые инструменты командной строки Unix предупреждали об отсутствии пустой строки.

В чем причина наличия лишней пустой строки?

Многие старые инструменты работают некорректно, если последняя строка данных в текстовом файле не заканчивается сочетанием новой строки или возврата каретки / новой строки. Они игнорируют эту строку, поскольку она заканчивается на ^ Z (eof).

Если вы попытаетесь объединить два текстовых файла вместе, вы будете намного счастливее, если первый из них закончится символом новой строки.

Помимо того факта, что это более приятная позиция курсора, когда вы перемещаетесь в конец файла в текстовом редакторе.

Наличие новой строки в конце файла обеспечивает простую проверку того, что файл не был усечен.

Аргумент может также быть сделан для более чистых различий, если вы добавляете в файл по тем же причинам Почему в списке допускаются конечные запятые?

Следующее скопировано (и немного обрезано) из связанного ресурса:

Изменение:

s = [
  'manny',
  'jack',
]

чтобы:

s = [
  'manny',
  'jack',
  'roger',
]

включает только однострочное изменение в diff:

  s = [
    'manny',
    'jack',
+   'roger',
  ]

Это лучше, чем запутанная многострочная разница, когда запятая не указана:

  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'

Без этого файл на самом деле не идентифицируется как текстовый файл. Теперь, когда мы добавим код в этот текстовый файл, мы не будем удалять эту начальную новую строку, которая сама определяет текстовый файл .