31–40 of 40 posts
This doesn't matter even remotely and it is the height of bike shedding to even have a discussion about it.
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.
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.
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.
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 troub…
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.
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.
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 troub…
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.
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.
Earlier quoted context omitted.
"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.
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.
Earlier quoted context omitted.
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.
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.