Ask HN: Should source files always end in a new line? | Hacker News Reader

Ask HN: Should source files always end in a new line?

10 pointsbreck37 comments

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.

I mean, I’ve found it very interesting to see different pros of ending a file in a new line I would have never even considered.

Agreed, I hate the attitude of shutting down discussion.

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.

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.

That's a cosmetic difference not a functional one.

Noise is not cosmetic.

Generally I would say yes. POSIX dictates that a line must end in newline, and some tools rely on it. See https://stackoverflow.com/a/729795

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.

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.

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 <textfiles>

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.

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.

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.

https://black.readthedocs.io/en/stable/

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.

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.

"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.

Consistency is an ocd thing.

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.

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.

They do mean an end of line character (linefeed on Linux), not an empty line by itself (i.e. not something like `hello\n\n`).

> 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.

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.

Reply on news.ycombinator.com