Why is it recommended to have empty line in the end of a source file?

Question

Some code style tools recommend this and I remember seeing some unix command line tools warning about missing empty line.

What is the reasoning for having an extra empty line?

Glaive

Some tools fail to work if the file doesn't end with a newline. That is different than having an empty line at the end (which would be 2 newlines). – Hypodermis

The text editors Gedit and Nano (and reportedly Vim) will append an empty line to any documents you save. – Portly

Do you mean empty line (\n\n) or new line \n? – Sushi

cat the file on a shell and you'll know why. If your file makes my shell's prompt appear in any other place than the one it should be (at the beginning of the line) I will probably hate you. ;) – Outlier

en.wikipedia.org/wiki/Newline#Interpretation – Spendthrift

Better (more general) answers re text files in general:: #730192 – Chiefly

My question is, at this point of time, is this recommendation still relevant? – Photoelectron

"Some code style tools" Which ones? – Adeleadelheid

@Adeleadelheid it might be harder to find any style tools which do not give such a warning. To answer your question about which tools issue the warning, SonarQube and Checkstyle are just two examples. – Aronoff

btw it's not an "Extra empty line" at all. It's just that the last line is properly terminated. It can't be called a line (according to Posix definition of a text file) if it doesn't end in a newline. – Aronoff

Answer 1

Many older tools misbehave if the last line of data in a text file is not terminated with a newline or carriage return / new line combination. They ignore that line as it is terminated with ^Z (eof) instead.

Rael

@NickM Almost all POSIX/Unix command-line tools that take text input or read a text file assume a line ending (\n) at end of file. Several text editors, like Vim, and several compilers (notably C++ and Python) will issue warnings. (In C++'s case, the standard explicitly requires this.) – Trademark

So what you're saying is ... it's a cargo cult – Afroasiatic

Yet you could have text on the last line, the question mentions an empty line \n\n. – Adelaidaadelaide

Answer 2

If you try to concatenate two text files together, you will be much happier if the first one ends with a newline character.

Euhemerism

When do you ever concatenate files though, and won't have the option to add newlines in between during concatenation? – Ouachita

@Ouachita eg. when you do cat file1 file2 file3 – Coniferous

@Coniferous You can just have file2 be only newlines, so you do have the option (or rather cat file1 newlinefile file2 newlinefile file3). Also that was not "when" but "how". – Yanina

@Yanina consider a bunch of files (logs, data produced in parallel, etc), you may want to do cat file*, and there isn't an easy way to manually insert newlines. – Azotize

Answer 3

An argument can also be made for cleaner diffs if you append to the file following the same reasoning as Why are trailing commas allowed in a list?

The following is copied (and trimmed a bit) from the linked resource:

Changing:

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

to:

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

involves only a one-line change in the diff:

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

This beats the more confusing multi-line diff when the trailing comma was omitted:

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

Kameko

Answer 4

Apart from the fact that it is a nicer cursor position when you move to the end of a file in a text editor.

Having a newline at the end of the file provides a simple check that the file has not been truncated.

Eustace

The file might be truncated and you would never even kn – Alcheringa

Nothing stops a file from having newlines somewhere in the middle, and the file could easily be truncated right there. – Ouachita

@Ouachita true, but it's a good heuristic for free. Random truncation is unlikely to result in a newline at the end. – Susan

Answer 5

The question, and most of the existing answers, seem to be based on a misconception.

The ASCII control character commonly referred to as "newline" (U+000A LINE FEED, \n in C) does not start a new line of a (Unix-style) text file. It ends the current line of a text file. If the last character of a text file is U+000A, there is not an empty line "in between" the U+000A and the filesystem's EOF marker (however that is implemented). Conversely, if the last character of a (nonempty) text file is not U+000A, the last line of the file has not been ended—it is said to be "incomplete".

This would probably be clearer with some examples:

This file contains two complete lines of text. It does not contain a third empty line.

$ printf 'first\nsecond\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a         first.second.

This file contains a third empty line.

$ printf 'first\nsecond\n\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a0a       first.second..

And this file contains only one complete line, plus a second incomplete line.

$ printf 'first\nsecond' | xxd
00000000: 6669 7273 740a 7365 636f 6e64            first.second

Sometimes an incomplete final line is what you want—for instance, having a newline in between the final ?> of a PHP script, and EOF, can cause extra whitespace to be emitted into the rendered HTML at a bad location (I would link to concrete examples but I am not having any luck finding one, this morning). Therefore, good text editors will clearly distinguish all three of the above cases in their UI.

However, older text-processing tools often mishandle incomplete final lines. For instance, some implementations of wc won't count an incomplete final line as a line, and some implementations of vi will silently add a newline to a file that doesn't end with one, whether you want it to or not. Therefore, you should only use incomplete final lines when you have a specific reason to need them.

(Note: As far as I know, everything I just said is also true of DOS-style text files, where the two-byte control sequence U+000D U+000A is used to end a line, instead of just U+000A.)

Harday

Answer 6

The empty line in the end of file appears so that standard reading from the input stream will know when to terminate the read, usually returns EOF to indicate that you have reached the end. The majority of languages can handle the EOF marker. It is there for that reason from the old days, under DOS, the EOF marker was F6 key or Ctrl-Z, for *nix systems, it was Ctrl-D.

Most, if not all, will actually read right up to the EOF marker so that the runtime library's function of reading from input will know when to stop reading any further. When you open the stream for Append mode, it will wipe the EOF marker and write past it, until a close is explicitly called in which it will insert the EOF marker at that point.

Older tools were expecting a empty line followed by EOF marker. Nowadays, tools can handle the empty line and ignore it.

Huntington

^D was not "the EOF marker". Pressing ^D caused the shell to close the write side of the pipe that the foreground process group was reading from, so that a read from that pipe returned EOF. There is no "EOF marker". – Hypodermis

@William Pursell You mistakenly conflated *NIX and Windows. Legacy Windows/DOS absolutely used an EOF marker (26, 0x1a) embedded usually at the end of most files as a holdover for compatibility with ancient CP/M (Who the heck used CP/M after 1983?). Other "fun": \r\n instead of \n, DOS calls using a mix of ASCIIZ and ASCII$. Even worse, later on Windows usually insert an Unicode byte order mark (BOM) at the beginning of most text files. Lovely "uniqueness." – Anacreontic

Answer 7

Also when you modify file and appends some code at the end of file - diff (at least git diff in standard coniguration) will show that you changed the last line, while the only thing you've actually done - added a newline symbol. So cvs reports become less convenient.

Comedo

Answer 8

It's because of the definition of what a text file is. When you create a new text file in any unix environment, the contents of that file is the new line character '\n'

Without this, the file isn't really identified as a text file. Now once we add code to this text file, its about not removing this initial new line that defines a text file itself.

Sezen

Answer 9

Some languages define their input file in terms of input lines, where each input line is a series of characters terminated by a carriage return. If their grammar is so defined, then the last valid line of the file must be terminated by a carriage return too.

Implacental