icxxna
Last Updated: February 25, 2016
·
8.412K
· allysonbeckers
Avatar

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

Say Thanks
Respond

10 Responses
Add your response

5247
D42a7264714dee5006b9c99d2567a320

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
8b5f824507f3ff7c3060b5571b34571c

@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
D42a7264714dee5006b9c99d2567a320

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
D42a7264714dee5006b9c99d2567a320

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
Caccedb9c5a2956a125c2489dde877c2

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
Avatar

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
Caccedb9c5a2956a125c2489dde877c2

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
D42a7264714dee5006b9c99d2567a320

@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
Mich400x400

@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
D42a7264714dee5006b9c99d2567a320

@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