Некоторые инструменты стиля кода рекомендуют это, и я помню, как некоторые инструменты командной строки Unix предупреждали об отсутствии пустой строки.
В чем причина наличия лишней пустой строки?
language-agnostic
coding-style
eof
Петтери Хиетавирта
источник
источник
\n\n) или новую строку\n?catфайл на оболочке, и вы будете знать, почему. Если из-за вашего файла приглашение моей оболочки появится не в том месте, где оно должно быть (в начале строки), я, вероятно, вас ненавижу. ;)Ответы:
Многие старые инструменты работают некорректно, если последняя строка данных в текстовом файле не заканчивается сочетанием новой строки или возврата каретки / новой строки. Они игнорируют эту строку, поскольку она заканчивается на ^ Z (eof).
источник
\n) в конце файла. Несколько текстовых редакторов, таких как Vim, и несколько компиляторов (особенно C ++ и Python) будут выдавать предупреждения. (В случае C ++ стандарт явно требует этого.)\n\n.Если вы попытаетесь объединить два текстовых файла вместе, вы будете намного счастливее, если первый из них закончится символом новой строки.
источник
Помимо того факта, что это более приятная позиция курсора, когда вы перемещаетесь в конец файла в текстовом редакторе.
Наличие новой строки в конце файла обеспечивает простую проверку того, что файл не был усечен.
источник
Аргумент может также быть сделан для более чистых различий, если вы добавляете в файл по тем же причинам Почему в списке допускаются конечные запятые?
Следующее скопировано (и немного обрезано) из связанного ресурса:
Изменение:
чтобы:
включает только однострочное изменение в diff:
Это лучше, чем запутанная многострочная разница, когда запятая не указана:
источник
В конце файла появляется пустая строка, так что стандартное чтение из входного потока будет знать, когда прекратить чтение, обычно возвращает EOF, чтобы указать, что вы достигли конца. Большинство языков могут обрабатывать маркер EOF. Именно по этой причине в старые времена под DOS маркером EOF была клавиша F6 или Ctrl-Z, для * nix-систем это был Ctrl-D.
Большинство, если не все, на самом деле будут читать вплоть до маркера EOF, так что функция чтения во время выполнения библиотеки будет знать, когда прекратить чтение дальше. Когда вы открываете поток для режима добавления, он стирает маркер EOF и записывает его после него, пока явно не будет вызвано закрытие, в которое он вставит маркер EOF в этой точке.
Старые инструменты ожидали пустую строку, за которой следовал маркер EOF. В настоящее время инструменты могут обрабатывать пустую строку и игнорировать ее.
источник
\r\nвместо того\n, чтобы вызывать DOS, используйте сочетание ASCIIZ и ASCII $. Хуже того, позже в Windows обычно вставляют метку порядка байтов Unicode (BOM) в начале большинства текстовых файлов. Прекрасная "уникальность".Также, когда вы изменяете файл и добавляете некоторый код в конец файла - diff (по крайней мере, git diff в стандартной конфигурации) покажет, что вы изменили последнюю строку, а единственное, что вы на самом деле сделали - добавили символ новой строки. Таким образом, cvs отчеты становятся менее удобными
источник
Некоторые языки определяют свой входной файл в терминах строк ввода, где каждая строка ввода представляет собой последовательность символов, оканчивающихся переводом каретки. Если их грамматика определена таким образом, то последняя действительная строка файла также должна заканчиваться переводом каретки.
источник
Это из-за определения, что такое текстовый файл. Когда вы создаете новый текстовый файл в любой среде unix, содержимое этого файла представляет собой символ новой строки '\ n'
Без этого файл на самом деле не идентифицируется как текстовый файл. Теперь, когда мы добавим код в этот текстовый файл, мы не будем удалять эту начальную новую строку, которая сама определяет текстовый файл .
источник