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

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?

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.

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

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.

An argument can also be made for cleaner diffs if you append to the file following the same reasoning as https://stackoverflow.com/questions/11597901/why-does-python-allow-a-trailing-comma-in-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'
  ]

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.

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.)

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.

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.

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.