Worth Reading: Why You Should End Your Source Files With a Newline
Pointing to a well-argued dev.to article on why source files should end with a newline, and a short note on why it's worth adopting as a habit.
This one isn’t mine — it’s a genuinely good explanation of a small convention I’ve come to rely on, and it deserves a direct link rather than a rewrite.
Original article: Why You Should End Your Source Files With a New Line by documendous on dev.to.
The short version of the argument: POSIX defines a text file as a sequence of lines each ending in a newline, so a file missing that trailing newline technically isn’t a well-formed text file — and a surprising number of tools quietly assume it is. Git treats the presence or absence of that final newline as a real diff, which means a missing newline turns an unrelated one-line change into edits on two files instead of one the moment someone’s editor “fixes” it. Linters and formatters increasingly enforce the convention outright, and file concatenation can silently merge the last line of one file into the first line of the next if the newline isn’t there.
None of that is dramatic on its own. What makes it worth caring about is how often it shows up as noise: an unrelated PR with an extra one-line diff because someone’s editor auto-added a trailing newline, or a merge that looks messier than the actual change warranted. It’s a one-time .editorconfig setting (insert_final_newline = true) or linter rule, and then it’s simply not a thing anyone has to think about again.
Go read the original piece — it goes through the POSIX, version-control, editor, linter, and file-concatenation angles in more detail than is worth repeating here, and it’s a quick read.