Should source files always end in a new line?
What is the best thinking on this matter?
This doesn't matter even remotely and it is the height of bike shedding to even have a discussion about it.
Yes - they play more nicely with cat and other unix command line tools. That is the reason for the convention.
The only difference I can think of is when appending to a file.
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.
POSIX text files have lines terminated in a newline and so the POSIX text files always end in a newline.
Source files are text files so they end in a new line.
Source files are text files.
echo “new line” >> textfile
cat
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.
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.
Doesn't matter. Pick one. Enforce it with a linter. Move on with your life.
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.
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).
It makes it easier to parse a text file without special cases.
It's an insignificant reason, but that's why it's traditionally recommended.
Yes, purely because otherwise diffs get this added:
\ No newline at end of file
GitHub gives me an angry looking red circle if I don't so I add one
OP must've got a PR about this blocking him from merging.
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.
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.
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.
Whatever your code formatter says. ESLint adds one for me so my source files have a newline.
Consistency is king - yes. Newline at EOF, trim trailing whitespace.
if you don't end the files with a new line, adding a new non-empty line in the end modifies 2 non-empty lines instead of one.
I'd prefer it, as would most?
Yes please, even if there's no need for a final newline just do it.
I say yes, whatever the plain-text content it is.
Pro: ???
Con: Your file is 1 byte larger.