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


232

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

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


7
Некоторые инструменты не работают, если файл не заканчивается новой строкой. Это отличается от того, что в конце есть пустая строка (это будет 2 строки).
Уильям Перселл

2
Вы имеете в виду пустую строку ( \n\n) или новую строку \n?
Сиро Сантилли 郝海东 冠状 病 六四 事件 法轮功

13
catфайл на оболочке, и вы будете знать, почему. Если из-за вашего файла приглашение моей оболочки появится не в том месте, где оно должно быть (в начале строки), я, вероятно, вас ненавижу. ;)
ThiefMaster

2
Столкнулся с этим старым вопросом и просто не может поверить, что каждый отдельный ответ пытается оправдать недостатки и недостатки других инструментов и систем, говоря, что современные кодеры должны добавлять символ, который не имеет значения в самом коде. Поговорим о 5 обезьянах в клетке! :-D
Амос М. Карпентер

1
Лучшие (более общие) ответы на текстовые файлы в целом :: stackoverflow.com/questions/729692/…
Рубен Бартелинк

Ответы:


188

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


1
Спасибо за ответ! Какие-нибудь примеры популярных инструментов, которые могут демонстрировать такое поведение?
Ник Меррилл

8
@NickM Почти все инструменты командной строки POSIX / Unix, которые принимают текстовый ввод или читают текстовый файл, предполагают конец строки ( \n) в конце файла. Несколько текстовых редакторов, таких как Vim, и несколько компиляторов (особенно C ++ и Python) будут выдавать предупреждения. (В случае C ++ стандарт явно требует этого.)
greyfade

5
Так что вы говорите ... это культ груза
Jaykul

Тем не менее, у вас может быть текст в последней строке, вопрос упоминает пустую строку \n\n.
Jinawee

57

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


Когда вы когда-нибудь объединяете файлы, и у вас не будет возможности добавлять новые строки между ними во время объединения?
Рудей

38

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

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


221
Файл может быть обрезан, и вы никогда не узнаете
Саймон Никерсон

Ничто не мешает файлу иметь переносы где-то посередине, и файл может быть легко обрезан прямо здесь.
Рудей

26

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

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

Изменение:

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

чтобы:

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

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

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

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

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

Ответы только на ссылки не считаются ценными на SO. Пожалуйста, скопируйте соответствующую информацию здесь, сохраняя атрибуцию.
Ишервуд

17

В конце файла появляется пустая строка, так что стандартное чтение из входного потока будет знать, когда прекратить чтение, обычно возвращает EOF, чтобы указать, что вы достигли конца. Большинство языков могут обрабатывать маркер EOF. Именно по этой причине в старые времена под DOS маркером EOF была клавиша F6 или Ctrl-Z, для * nix-систем это был Ctrl-D.

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

Старые инструменты ожидали пустую строку, за которой следовал маркер EOF. В настоящее время инструменты могут обрабатывать пустую строку и игнорировать ее.


6
^ D не был "маркером EOF". Нажатие ^ D заставило оболочку закрыть сторону записи канала, с которого читала группа процессов переднего плана, так что чтение из этого канала вернуло EOF. Там нет "EOF маркер".
Уильям Перселл

@William Pursell Вы ошибочно отождествляли * NIX и Windows. В старых версиях Windows / DOS абсолютный маркер EOF (26, 0x1a), встроенный обычно в конце большинства файлов, использовался в качестве удерживающего устройства для совместимости с древним CP / M (Кто, черт возьми, использовал CP / M после 1983 года?). Другое «веселье»: \r\nвместо того \n, чтобы вызывать DOS, используйте сочетание ASCIIZ и ASCII $. Хуже того, позже в Windows обычно вставляют метку порядка байтов Unicode (BOM) в начале большинства текстовых файлов. Прекрасная "уникальность".

9

Также, когда вы изменяете файл и добавляете некоторый код в конец файла - diff (по крайней мере, git diff в стандартной конфигурации) покажет, что вы изменили последнюю строку, а единственное, что вы на самом деле сделали - добавили символ новой строки. Таким образом, cvs отчеты становятся менее удобными


5

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


3

Это из-за определения, что такое текстовый файл. Когда вы создаете новый текстовый файл в любой среде unix, содержимое этого файла представляет собой символ новой строки '\ n'

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.