Иногда при просмотре диффов коммитов через git log или git diff можно заметить следующий вывод:

\ No newline at end of file

Или на GitHub в интерфейсе для просмотра диффов:

Почему это так важно, что Git и GitHub предупреждают нас об этом? Давайте разберемся.

Что такое символ переноса строки?

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

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

Для набора символа переноса строки достаточно нажать клавишу "Enter", но на разных платформах этот символ закодируется по-разному:

• в Unix-совместимых системах (включая современные версии macOS) используется один символ перевода строки (LF);
• в Windows используется сразу два символа — возврат каретки (CR) и перевод строки (LF);
• в очень старых версиях Mac OS (до 2001 года) использовался один символ CR.

Как видите, Windows точнее всего эмулирует поведение печатной машинки.

В языках программирования символ новой строки часто кодируют при помощи бэкслэш-последовательностей, таких как \n или \r\n. Нужно понимать разницу между такой последовательностью и настоящим символом переноса строки. Если в редакторе в файле *.txt просто набрать \n и сохранить, то вы получите ровно то, что написали. Символом переноса строки оно не станет. Нужно что-то, что заменит эти бэкслэш-последовательности на настоящие символы переноса строки (например, компилятор или интерпретатор языка программирования).

Почему перенос строки в конце файла важен?

Согласно определению из стандарта POSIX, который тоже пришёл к нам из эпохи печатных машинок:

Строка — это последовательность из нуля или более символов, не являющихся символом новой строки, и терминирующего символа новой строки.

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

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

Давайте, например, через Python создадим такой файл со сломанными строками:

with open("broken.txt", "w") as f:
    f.write("qwe\n")
    f.write("asd\n")
    f.write("zxc")

Сколько по-вашему в этом файле строк? Три? Давайте посмотрим, что об этом файле думает утилита wc, которая с флагом -l умеет считать количество строк в файле:

$ wc -l broken.txt 
2 broken.txt

Упс! wc нашла только 2 строки!

Давайте создадим еще один файл:

with open("broken2.txt", "w") as f:
    f.write("rty\n")
    f.write("fgh\n")
    f.write("vbn")

И попробуем теперь склеить два созданных файла при помощи утилиты cat:

$ cat broken.txt broken2.txt 
qwe
asd
zxcrty
fgh
vbn

Название cat — это сокращение от "конкатенация", и никак не связано с котиками. А жаль.

И опять какой-то странный результат! В большинстве случаев это не то, чего вы бы ожидали, но вполне возможны ситуации, когда вам нужен именно такой результат. Именно поэтому утилита cat не может самостоятельно вставлять отсутствующие символы переноса строки, иначе это сделало бы её поведение неконсистентным.

Это только пара примеров, но многие другие утилиты, которые работают с текстом (например, diff, grep, sed), имеют такие же проблемы. Собственно говоря, это даже не проблемы, а их задокументированное поведение.

Ещё доводы:

• при дозаписи содержимого в конец файла без переноса строки получится некрасивый дифф — будет изменена последняя строка (хотя на ней всего лишь добавился символ переноса);
• файл с переносом строки и без переноса строки — это два разных файла; для diff и git diff единственный способ отобразить разницу между ними — это напечатать сообщение об отсутствии символа переноса строки;
• согласно стандарту языка C (до 2014 года), непустые файлы с исходным кодом должны заканчиваться символом переноса строки.

Настраиваем редактор

Самый простой способ перестать думать о пустых строках и начать жить — это настроить свой текстовый редактор или IDE на автоматическое добавление символа переноса строки в конец файлов:

• PyCharm и другие IDE JetBrains: Settings > Editor > General > Ensure an empty line at the end of a file on Save;
• VS Code: "files.insertFinalNewline": true.

Для других редакторов смотрите настройку здесь.

Кстати, если вы пользуетесь форматтером black, то у меня хорошие новости — он всегда добавляет перенос строки в конец всех файлов *.py.

Заключение

Возможно, такая маленькая деталь, как перенос строки в конце файла и не кажется очень важной, а тема вообще кажется спорной, но боюсь, что у нас нет другого выбора, кроме как принять это правило за данность и просто выработать привычку (или настроить инструментарий) всегда ставить символ новой строки в любых текстовых файлах, даже если этого не требуется явно. Это считается распространённой хорошей практикой, и как минимум убережёт вас и ваших коллег от всяких неожиданных эффектов при работе с утилитами Unix.

В текстовом редакторе это выглядит как лишняя пустая строка в конце файла:

Дополнительное чтение

• StackOverflow: No newline at end of file;
• StackOverflow: Why should text files end with a newline?;
• thoughtbot — No Newline at End of File.