Empty new line at the end of the Java source files

Question

In my current project, we always insert an empty new line at the end of the Java source files. We also enforce this with CheckStyle (with error level).

I was searching fo

Answer 1

I think they are trying to ensure every file ends with a trailing newline character. This is different from ending with a blank line, a.k.a. empty newline.

Edit: As @Easy Angel succinctly clarified in the comments: trailing newline = "\n" and blank line = "\n\n"

I think either:

1. your lead is either mandating that every file ends with a newline character, but its being misinterpreted as mandating that every file end with a blank line (i.e. an empty line that ends in a newline), or else

2. they are trying to ensure every file ends with a newline character by actually mandating every file end with a blank line (a.k.a. empty line that ends with a newline), thereby ensuring files ends with at least one newline (and possibly redundant additional newline - overkill?).

Unless the editor actually shows newline symbols, its not always clear in some editors that a file:

1. DOES NOT END a newline at all,
2. ENDS with a single trailing newline, or
3. ENDS with a blank newline, i.e. 2 trailing newlines

I think most modern source code editors insert a trailing newline. However, when using older more general editors, I would always try to ensure my source code files (and text files in general) always ended with a trailing newline (which occasionally came out as a blank line/empty newline depending on the editor I was using) because:

1. when using cat to display the file on the command line, if the file lacked a trailing newline, the next output (like the shell prompt or a visual delimiter a script may output between files) would end up appearing right after the last non-newline character rather than starting on a newline. In general, the trailing newline made files more user- and script- friendly.

2. I believe some editors (I can't remember any specifics) would automatically insert a trailing newline if the text file lacked one. This would make it appear like the file was modified. It would get confusing if you have a bunch of files open in different windows and then go to close all of them - the editor prompts you to save but you are unsure whether you made "real changes" to the file or its just the auto-inserted newline.

3. Some tools like diff and some compilers will complain about a missing trailing newline. This is more noise that users and tools may have to deal with.

---

Edit:

About editors adding newlines and not being able to see whether there's a newline vs blank newline at the end of the file, I just tested Vim, Eclipse, and Emacs (on my Windows system with Cygwin): I opened a new file, typed 'h' 'e' 'l' 'l' 'o' and saved without hitting [ENTER]. I examined each file with od -c -t x1.

1. Vim did add a trailing newline.
2. Emacs did add a trailing newline.
3. Eclipse did NOT add a trailing newline.

But

1. Vim did NOT allow me to cursor down to a blank line under "hello".
2. Emacs did allow me to cursor down to a blank line under "hello".
3. Eclipse did NOT allow me to cursor down to a blank line under "hello".

Interpret as you like.

---

My personal practice is to try to ensure text files end with a trailing newline. I just feel there's the least surprise to people and tools with this is the case. I wouldn't treat source files any different from text files in this respect.

Google turns up this:

which, as of this edit, show hits that talk about warnings about a missing trailing newline coming from C compilers, svn (because of diff), diff, etc. I feel there's a general expectation that text files (source files included) end with a trailing newline and least surprising (and less noisy) when they tend to be there.

Finally this is interesting:

Sanitizing files with no trailing newline
Text files should have all their lines terminated by newline characters (ie, \n). This is stated by POSIX, that says that a text file is

A file that contains characters organized into zero or more lines.
A line, in turn, is defined as
* A sequence of zero or more non- characters plus a terminating character.

---

HOWEVER, all that said, this is just my personal practice. I'm happy to share my opinion to anyone that asks, but I don't foist this on anyone. I don't feel this is something worth mandating, like I say here:

While I'm one whose all for consistency, I'm also against micromanaging every bit of style. Having a huge list of coding conventions, particularly when some of them seem arbitrary, is part of what discourages people from following them. I think coding guidelines should be streamlined to the most valuable practices that improve the -ilities. How much is readability, maintainability, performance, etc improved by mandating this practice?