Only reason I do it is because if you're adding onto a file, git will say the (prior) last line is modified because you have added the newline to it. But it's not a really big deal, I don't enforce it with any linter/CI. It's just 0.01% annoying to see a 20 line commit say 21 lines changed.
Ending text files with a newline makes a functional difference. For one, no more diff noise from `\ no newline at end of file` in various Git diff views.
It's not a big deal either way, but ending in a new line makes consistent the property that each line of text ends in a new line character (as opposed to EOF).
I was thinking a while ago about formatting restrictions that could make sense in a language (programming, markup, whatever) to simplify things (… and which would surely also annoy some users, but what’s life without fun?). Things like requiring tabs (partly because in a vacuum they’re simply better than spaces, and partly to protest against YAML which goes the other way), and banning carriage returns (how much trouble has supporting both ␍␊ and ␊ caused, I wonder? It’s not a little). Requiring EOL at EOF was also one I thought of.
One project you may be interested in is Black for python.
It's a code formatter that provides one style with very limited configuration. The idea being the rigidness removes bike shedding and forces consistency.
Of course you can use any code formatter and configure it to your liking, but there's something to be said about not giving the user levers to pull and argue about. Everyone just download Black, and you're good to go.
Tabs versus spaces is an interesting one. I was 100% convinced spaces were the way to go. But then ~1.5 yrs ago made a lang with tabs and it was a lot easier to work with in a spreadsheet IDE interface. I'm in the midst of a big refactor of one of my upstream libraries so that I could at least make it an easy thing to switch to tabs if they are indeed better.
If you and your toolchain don’t see them as text files and never will, and you never use your editor to edit other text files (e.g. /etc/…), you’re probably ok without a newline at eof.
"What" to do matters less than consistency (in most cases - if you have technical reasons to pick one or the other, do so). Use a linter that can auto-fix everything and enforce that.
The benefit of consistency in this case would be that your git diffs aren't littered with irrelevant changes because someone prefers one convention and someone else prefers the other.
Which convention is chosen as the default doesn't usually matter (unless some of the edge-cases raised by the other comments are relevant to you), but what matters is what when you look at a diff it isn't polluted.
> The benefit of consistency in this case would be that your git diffs aren't littered with irrelevant changes because someone prefers one convention and someone else prefers the other.
If you didn't care about consistency you wouldn't be changing others people code to be consistent.
You would make your own change and that relevant change remains inconsistent. That's it.
>Which convention is chosen as the default doesn't usually matter (unless some of the edge-cases raised by the other comments are relevant to you), but what matters is what when you look at a diff it isn't polluted.
Again the diff isn't polluted. It is simply inconsistent. This is different from two people battling over which convention to follow (which is what you are referring to). In the later case, yes you will see diffs where one person attempts to change the convention, in the former case you simply see a diff where the change doesn't follow a convention.
Do you mean an empty line? (since, as others have pointed out, every line ends in a newline character, for most text editors).
I like having the extra line, it is a very minimal difference, but this way it is possible to copy the last line by copying "down" rather than copying "out" to the end of the line.
Most importantly, pick a linter that can automatically fix it. I use pre-commit (https://pre-commit.com) for that. As a bonus, it supports other, language-specific linters.
Ages ago MS's C preprocessor would ignore directives on the last line if it didn't end in a newline. I'm sure that's fixed by now, but who knows how many tools still suffer from it.
It shouldn't have to end in a newline, but I still end them all with a newline.
Yes. Not because it is definitively the right answer (though it is my preference), but because a decision that's made and enforced allows the conversation to move on to other things.
And to enforce it? Try https://editorconfig.org/ which is supported natively by many editors (eg Visual Studio) and via plugins in others (eg VS Code).
All it needs is a .editorconfig file in your folder and you get a handful of helpful settings (trim trailing whitespace, end with a newline, tabs vs spaces, ASCII vs UTF8, etc) in a simple file of rules that cascade down your folder hierarchy. Usually just add it next to your .gitignore, README.md, etc.
39 comments
[ 2.9 ms ] story [ 55.8 ms ] threadCon: Your file is 1 byte larger.
Starting with an empty file you’re on a new line.
But if you don’t end every line with a newline character then your next line will end up on the same line in the file as the last one.
Everything is worth discussing, just not ad nauseam. I've never really question newline at the end of a file so this is interesting to me too.
Source files are text files so they end in a new line.
It's a code formatter that provides one style with very limited configuration. The idea being the rigidness removes bike shedding and forces consistency.
Of course you can use any code formatter and configure it to your liking, but there's something to be said about not giving the user levers to pull and argue about. Everyone just download Black, and you're good to go.
https://black.readthedocs.io/en/stable/
It's an insignificant reason, but that's why it's traditionally recommended.
It's having me think about the way prs should be done on divisive topics.
On one hand you have this "guy" who thinks he's gods gift to programming demanding a new line be added to all 30 files you're adding to the project.
On the other hand that "guy" is you.
What then? In both cases.
Being consistent is orthogonal to readability and modularity and extensibility.
It's actually delusional. Most programmers want to be consistent based simply off a feeling but in actuality the benefit of consistency is minimal.
You "are" that guy.
Which convention is chosen as the default doesn't usually matter (unless some of the edge-cases raised by the other comments are relevant to you), but what matters is what when you look at a diff it isn't polluted.
If you didn't care about consistency you wouldn't be changing others people code to be consistent.
You would make your own change and that relevant change remains inconsistent. That's it.
>Which convention is chosen as the default doesn't usually matter (unless some of the edge-cases raised by the other comments are relevant to you), but what matters is what when you look at a diff it isn't polluted.
Again the diff isn't polluted. It is simply inconsistent. This is different from two people battling over which convention to follow (which is what you are referring to). In the later case, yes you will see diffs where one person attempts to change the convention, in the former case you simply see a diff where the change doesn't follow a convention.
I like having the extra line, it is a very minimal difference, but this way it is possible to copy the last line by copying "down" rather than copying "out" to the end of the line.
> have pointed out, every line ends in a newline character, for most text editors).
My colleagues always add changes that end with that `\ No newline at end of file` diff for certain source files.
It shouldn't have to end in a newline, but I still end them all with a newline.
And to enforce it? Try https://editorconfig.org/ which is supported natively by many editors (eg Visual Studio) and via plugins in others (eg VS Code). All it needs is a .editorconfig file in your folder and you get a handful of helpful settings (trim trailing whitespace, end with a newline, tabs vs spaces, ASCII vs UTF8, etc) in a simple file of rules that cascade down your folder hierarchy. Usually just add it next to your .gitignore, README.md, etc.