Пустая новая строка в конце исходных файлов java

Ответ 1

Я думаю, что они пытаются обеспечить, чтобы каждый файл заканчивался символом новой строки. Это отличается от окончания пустой строкой, пустой строки новой строки a.k.a.

Изменить: Поскольку @Easy Angel кратко разъясняется в комментариях: trailing newline = "\n" и пустая строка = "\n\n"

Я думаю, что:

• ваше руководство либо обязано, чтобы каждый файл заканчивался символом новой строки, но его неверно истолковали как указание, что каждый файл заканчивается пустой строкой (т.е. пустой строкой, которая заканчивается в новой строке), или иначе

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

Если редактор фактически не отображает символы новой строки, в некоторых редакторах не всегда ясно, что файл:

• НЕ ЗАВЕРШАЕТ новую строку,
• ENDS с одной конечной новой строкой или
• ENDS с пустой новой строкой, т.е. 2 конечных символа новой строки

Я думаю, что большинство современных редакторов исходного кода вставляют конечную новую строку. Однако при использовании старых более общих редакторов я всегда старался, чтобы мои файлы исходного кода (и текстовые файлы в целом) всегда заканчивались завершающей новой строкой (которая иногда выходила как пустая строка/пустая строка в зависимости от редактор, который я использовал), потому что:

• при использовании cat для отображения файла в командной строке, если в файле отсутствует конечная новая строка, следующий вывод (например, приглашение оболочки или визуальный разделитель a script может выводиться между файлами) будет в конечном итоге появляется сразу после последнего символа новой строки, а не начинается с новой строки. В общем, конечная новая строка сделала файлы более удобными для пользователя и script.

• Я считаю, что некоторые редакторы (я не помню каких-либо особенностей) автоматически вставляли бы завершающую новую строку, если в текстовом файле ее не было. Это создало бы впечатление, что файл был изменен. Было бы странно, если бы у вас было множество файлов, открываемых в разных окнах, а затем закрыть их все - редактор предложит вам сохранить, но вы не уверены, сделали ли вы "реальные изменения" в файле или его просто авто- вставлена ​​новая строка.

• Некоторые инструменты, такие как diff, и некоторые компиляторы будут жаловаться на недостающую конечную новую строку. Это больше шума, с которым могут столкнуться пользователи и инструменты.

Edit:

О редакторах, добавляющих новые строки и не способных видеть, есть ли новая строка против пустой строки в конце файла, я только что протестировал Vim, Eclipse и Emacs (в моей системе Windows с Cygwin): я открыл новый файл, набрал 'h' 'e' 'l' 'l' 'o' и сохранен без удара [ENTER]. Я просмотрел каждый файл с помощью od -c -t x1.

• Vim добавил конечную новую строку.
• Emacs добавила конечную новую строку.
• Eclipse НЕ добавил конечную новую строку.

Но

• Vim НЕ разрешил мне курсор до пустой строки под "привет" .
• Emacs позволил мне перейти на пустую строку под "привет" .
• Eclipse НЕ разрешил мне курсор до пустой строки под "привет" .

Интерпретировать, как вам нравится.

Моя личная практика - попытаться обеспечить, чтобы текстовые файлы заканчивались завершающей новой строкой. Я просто чувствую, что наименьший сюрприз для людей и инструментов с этим имеет место. Я бы не рассматривал исходные файлы в отличие от текстовых файлов в этом отношении.

Google включает this:

который из этого редактирования показывает хиты, в которых говорится о предупреждениях о недостающей конечной новой строке, исходящей из компиляторов C, svn (из-за diff), diff и т.д. Я чувствую, что существует общее ожидание того, что текстовые файлы (включая исходные файлы ) заканчиваются конечной новой строкой и наименее удивительными (и менее шумными), когда они, как правило, существуют.

Наконец этот интересен:

Санитирование файлов без конечной новой строки
Текстовые файлы должны иметь все свои строки, завершаемые символами новой строки (т.е.\N). Об этом говорит POSIX, в котором говорится, что текстовый файл

Файл, содержащий символы, помещенные в ноль или более строк.
Строка, в свою очередь, определяется как  * Последовательность из нуля или более символов без символа.

ОДНАКО, все, что сказал, это только моя личная практика. Я рад поделиться своим мнением с любым, кто спрашивает, но я никому не навязываю это. Я не чувствую, что это что-то заслуживающее мандата, как я говорю здесь:

В то время как я - тот, у кого все для согласованности, я также против микроуправления каждым стилем. Наличие огромного списка соглашений о кодировании, особенно когда некоторые из них кажутся произвольными, является частью того, что препятствует людям следовать им. Я считаю, что руководящие принципы кодирования должны быть упорядочены до самых ценных практик, которые улучшают возможности. Насколько улучшена читаемость, ремонтопригодность, производительность и т.д., Задав эту практику?

Ответ 2

Вот хорошая причина для дополнительного прерывания линии в конце:

Если у вас есть файл без прерывания строки в конце, в следующий раз, когда файл будет отредактирован для добавления другой строки, большинство инструментов слияния будут думать, что существующая строка изменилась (я на 90% уверен, что SVN также делает).

В приведенном ниже примере строка, содержащая "последняя строка перед редактированием", не имеет разрыва строки. Если мы попытаемся добавить новую строку "последняя строка после редактирования", мы увидим, что обе строки 5 и 6 отмечены как измененные, но фактическое содержимое строки 5 в обеих версиях одинаково.

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

Хотя это может показаться неважным, скажем, один разработчик (A) на самом деле означал изменение содержимого последней строки, а другой разработчик (B) добавил новую строку. Если не использовать разрывы строк перед EOF, у вас возникает конфликт слияния, потому что разработчик B был вынужден также отредактировать предыдущую строку, чтобы добавить разрыв строки. И... кому нравятся конфликты CVS/SVN?

Ответ 3

Посмотрите этот вопрос SO..

Ответ, бесстыдно украденный у Ральфа Рикенбаха:

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

Поэтому я считаю это главным образом призраком прошлого. К сожалению, такие призраки могут укусить вас в хвост, если вы их не извратите. (Является ли ваш сервер сборки старым и использует старые сценарии оболочки для сводок и т.д.).

Ответ 4

Попробуйте вырезать/вставить весь файл. Что-то ошибка в checkstyle или eclipse:)

Ответ 5

Иногда ваш компилятор не анализирует его правильно:

Error: Reached end of file while parsing

Ответ 6

Помимо уже упомянутых обоснованных причин наличия конечного символа новой строки (возможные проблемы со старыми инструментами и diff), вот еще один способ взглянуть на него:

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

Ответ 7

Это просто стиль кодирования. Не болит и не помогает. Я бы не хотел, чтобы это беспокоило вас, похоже, что ваши команды предпочитают включать и пустую строку. На самом деле нет хорошего аргумента против этого, кроме того, почему кто-то достаточно заботится о том, чтобы на самом деле добавить его в checkstyle?

Ответ 8

Я никогда не слышал о таком требовании.

Фактически, я только что подтвердил, что программа Java будет работать без каких-либо ошибок компилятора/времени выполнения или предупреждений, если в конце файла нет пустой строки.

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

Ответ 9

Мы должны были сделать это для некоторого кода на С++, поскольку компилятор генерировал предупреждение об этом, и у нас была политика "без ошибок или предупреждений". Может быть, проблема кроется в другом месте... есть ли у вас отличный инструмент, который работает с haywire или инструментом слияния, который не может справиться с этим?

Это действительно неважно.