Чому в кінці вихідного файлу рекомендується мати порожній рядок?

232

Деякі засоби стилю коду рекомендують це, і я пам’ятаю, що я бачив деякі інструменти командного рядка unix, що попереджають про відсутність порожнього рядка.

Яке міркування про наявність додаткового порожнього рядка?

language-agnostic coding-style eof

— Петтері Хіетавірта
джерело

7

Деякі інструменти не спрацьовують, якщо файл не закінчується новим рядком. Це інакше, ніж порожній рядок у кінці (який би був 2 нових рядки).

— Вільям Перселл

2

Ви маєте на увазі порожній рядок ( \n\n) чи новий рядок \n?

— Ciro Santilli 郝海东冠状病六四事件法轮功

13

catфайл на оболонці, і ви дізнаєтеся чому. Якщо у вашому файлі запит моєї оболонки з’явиться в будь-якому іншому місці, крім того, яке має бути (на початку рядка), я, мабуть, ненавиджу вас. ;)

— ThiefMaster

2

Я зіткнувся з цим старим питанням і просто не може повірити, що кожна відповідь намагається виправдати недоліки та недоліки інших інструментів і систем, сказавши, що сучасні кодери повинні додати символ, який не має значення в самому коді. Поговоріть про 5 мавп у клітці! :-D

— Амос М. Карпентер

1

Краще (більш загальні) відповіді повторно текстові файли в загальному :: stackoverflow.com/questions/729692 / ...

— Рубен Bartelink

188

Багато старих інструментів погано поводяться, якщо останній рядок даних у текстовому файлі не закінчується новою лінією або комбінацією повернення та носії / нової лінії. Вони ігнорують цей рядок, оскільки він закінчується замість ^ Z (eof).

— Ральф М. Рікенбах
джерело

1

Дякую за відповідь! Будь-які приклади популярних інструментів, які можуть проявляти таку поведінку?

— Нік Меррілл

8

@NickM Практично всі інструменти командного рядка POSIX / Unix, які приймають текст або читають текстовий файл, передбачають рядок, що закінчується ( \n) в кінці файлу. Кілька текстових редакторів, як-от Vim, і кілька компіляторів (зокрема C ++ і Python) видають попередження. (У випадку C ++ це стандарт прямо вимагає.)

— greyfade

5

Отже, що ви говорите, це ... вантажний культ

— Джейкуль

Тим не менш, у вас може бути текст у останньому рядку, у питанні згадується порожній рядок \n\n.

— jinawee

57

Якщо ви спробуєте об'єднати два текстових файли разом, ви будете набагато щасливішими, якщо перший закінчиться символом нового рядка.

— user1809090
джерело

38

Крім того, що це приємніше положення курсору, коли ви переходите до кінця файлу в текстовому редакторі.

Новий рядок у кінці файлу забезпечує просту перевірку того, що файл не був усічений.

— rsp
джерело

221

Файл може бути врізаний, і ви ніколи не будете навіть кн

— Саймон Нікерсон

26

Аргумент також може бути зроблений для більш чистих розбіжностей, якщо ви додасте до файлу такі ж міркування, як і для чого в списку дозволені тривалі коми.

Далі скопійовано (і трохи обрізано) із пов'язаного ресурсу:

Зміна:

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

до:

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

передбачає лише зміну одноліній у диференціалі:

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

Це перемагає більш заплутану багаторядкову різницю, коли пропущена кома в кінці:

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

— Матіас Бак
джерело

Відповіді лише на посилання не вважаються цінними в SO. Скопіюйте сюди відповідну інформацію, зберігаючи атрибуцію.

— isherwood

17

Порожній рядок у кінці файлу з'являється таким чином, що стандартне зчитування з вхідного потоку буде знати, коли припинити зчитування, як правило, повертає EOF, щоб вказати, що ви досягли кінця. Більшість мов може працювати з маркером EOF. Саме тому зі старих часів у DOS маркер EOF був ключем F6 або Ctrl-Z, для систем * nix це був Ctrl-D.

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

Старіші інструменти очікували, що порожній рядок слід маркер EOF. У наш час інструменти можуть обробляти порожній рядок і ігнорувати його.

— t0mm13b
джерело

6

^ D не був "маркером EOF". Натискаючи ^ D, оболонка закрила сторону запису труби, з якої зчитувалася група процесу переднього плану, так що зчитування з цієї труби повернуло EOF. Немає "маркера EOF".

— Вільям Перселл

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

9

Крім того, коли ви модифікуєте файл і додаєте якийсь код в кінці файлу - diff (принаймні, git diff у стандартному coniguration) покаже, що ви змінили останній рядок, тоді як єдине, що ви насправді зробили - додав символ нового рядка. Тож резюме резюме стає менш зручним.

— prijutme4ty
джерело

5

Деякі мови визначають свій вхідний файл у рядках введення, де кожен рядок введення - це ряд символів, що закінчується поверненням каретки. Якщо їх граматика визначена таким чином, останній дійсний рядок файлу також повинен бути завершений поверненням каретки.

— Damien_The_Unbeliever
джерело

3

Це через визначення того, що таке текстовий файл. Коли ви створюєте новий текстовий файл у будь-якому середовищі Unix, його вмістом є новий символ рядка '\ n'

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

— Віктор Фернандес
джерело