icxxna
Last Updated: December 26, 2018
·
9.914K
· allysonbeckers

Don't forget that extra line!

In your Preferences.sublime-settings, make sure to add:

"ensure_newline_at_eof_on_save": true

...in order to save you (and others) headache when collaborating via version control. It also serves other advantages in the console and for compilers.

Here is an example of SourceTree warning about it:
SourceTree error example

10 Responses
Add your response

5247

Can you elaborate a little bit on the advantages and/or actual need for that newline? Is this practice still relevant and applicable everywhere?

over 1 year ago ·
5250

@dpashkevich I find it depends what you're working on - if you're using Python's PEP8 coding standards, rule W292 requires a new line at the end of the file.

over 1 year ago ·
5251

I've seen this requirement a lot in different code standards. Threads on SO suggest that it originated from C and the only reasonable argument that I've found is that it makes sure my shell prompts starts from new line after outputting file contents to the terminal with cat or something similar. I wonder if there are any other reasons.

over 1 year ago ·
5252

Also, worth noting that it's discouraged to put a new line at the end of PHP files since it may end up being in the response if you have a closing ?> tag in the end.

over 1 year ago ·
5253

There are a few different reasons to add a newline at eof, but as Allyson states, the main one is collaboration. Having a newline at the end of file has been an adopted practice for a while now. Traditional text editors like VIM add a newline at eof by default, and diff tools will most likely complain about the missing newline.

It is also important to note your line endings, which are also a source of headache sometimes, specially if you have developers using windows and *nix collaborating. Git has some good tools to deal with that via git-config options. GitHub has a nice summary here: Dealing with line endings

over 1 year ago ·
5255

What I know about it is, that a "real UNIX line" is a line which has a break at the end. This means, a line without a linebreak is not a complete line. Many UNIX/Linux programs rely on the fact that a line has a linebreak and if you use "grep" etc. which works mainly by reading/scanning lines, you're good to have a line ending for every line, also the last line to prevent odd behaviour using those programs.

over 1 year ago ·
5260

You're correct @thasmo. By -POSIX- definition a line must always end in a newline character, see 3.205 Line. Also interesting is the definition of a Text File, which states that a text file has 'characters organized into zero or more lines'.

over 1 year ago ·
5264

@thasmo, @diogoandre thanks! That's a kind of explanation I've been looking for. I'm not trying to argue against the practice, I was just curious of it's origin and practical implications.

over 1 year ago ·
5282

@dpashkevich That's also why it's an accepted good standard to not close your <?php tags in PHP-only files.

over 1 year ago ·
5284

@michd Yeah I learned about that recently. Feels very counter-intuitive (what? leave a tag unclosed?!) but makes sense.

over 1 year ago ·
Filed Under