6 ms·
Ask HN: Should source files always end in a new line?
What is the best thinking on this matter?
- swiley-gin 4y agoPOSIX 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.
- deleted 4y ago[deleted]
- zwieback 4y agoYes please, even if there's no need for a final newline just do it.
- FBISurveillance 4y agoConsistency is king - yes. Newline at EOF, trim trailing whitespace.
- daneel_w 4y agoI say yes, whatever the plain-text content it is.
- ChoGGi 4y agoI'd prefer it, as would most?
- smrk007 4y agoPro: ??? Con: Your file is 1 byte larger.
- eska 4y agoThe 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.
- squeaky-clean 4y agoOnly 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.
- bluefirebrand 4y agoThis doesn't matter even remotely and it is the height of bike shedding to even have a discussion about it.
- smrk007 4y agoI 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.
- spicybright 4y agoAgreed, 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.
- avgcorrection 4y agoEnding 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.
- bluefirebrand 4y agoThat's a cosmetic difference not a functional one.
- avgcorrection 4y agoNoise is not cosmetic.
- deleted 4y ago[deleted]
- sumnole 4y agoIt'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).
- chrismorgan 4y agoI 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.
- spicybright 4y agoOne 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/ https://black.readthedocs.io/en/stable/
- breck 4y agoTabs 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.
- P5fRxh5kUvp2th 4y agoIt makes it easier to parse a text file without special cases. It's an insignificant reason, but that's why it's traditionally recommended.
- treis 4y agoGitHub gives me an angry looking red circle if I don't so I add one
- chrismorgan 4y agoYes, purely because otherwise diffs get this added: \ No newline at end of file
- wruza 4y agoSource 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.
- IndepAmoeba 4y agoWhatever your code formatter says. ESLint adds one for me so my source files have a newline.
- strictfp 4y agoGenerally 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 https://stackoverflow.com/a/729795
- lambdafourtwo 4y agoOP 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.
- Nextgrid 4y ago"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.
- lambdafourtwo 4y agoConsistency 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.
- Nextgrid 4y agoThe 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.
- lambdafourtwo 4y ago> 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.
- jacobsenscott 4y agoYes - they play more nicely with cat and other unix command line tools. That is the reason for the convention.
- bee_rider 4y agoDo 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.
- avgcorrection 4y agoThey 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.
- mxz3000 4y agoDoesn't matter. Pick one. Enforce it with a linter. Move on with your life.
- Nextgrid 4y agoMost importantly, pick a linter that can automatically fix it. I use pre-commit (https://pre-commit.com https://pre-commit.com) for that. As a bonus, it supports other, language-specific linters.
- beej71 4y agoAges 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.
- mo_po2 4y agoif 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.
- kcartlidge 4y agoYes. 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/ 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.