4 ms·
A special case of (2) that is easy to do is to use tabs* for indentation and not do column alignment at all. To be clear, by "column alignment" I think we are b
by tczMUFlmoNk 3y ago
A special case of (2) that is easy to do is to use tabs* for indentation and not do column alignment at all. To be clear, by "column alignment" I think we are both referring to patterns like this:
myVars = {
first: 123,
second: 234,
afterward: 345,
also: 456,
} //~~~~~~~~ <- alignment
// or:
def my_long_function(arg1, arg2,
more_args,
and_some_more)
//~~~~~~~~~~~~~~~~~~ <- alignment
This is, e.g., what Go uses for struct fields, and what some Python style guides use for hanging function definitions. Regardless of tabs/spaces preference, both of these are independently bad because they churn diffs unnecessarily: if you change `afterward` to `afterward2` then you need to change all the nearby lines, and likewise if you change `my_long_function` to `my_longer_function`. Some formatters, like Black, Prettier, and (mostly) Rustfmt, avoid this pattern entirely, and they are better for it.
* You can do this and still use spaces if you prefer, too.
- junon 3y agoOr just configure your code formatter to do this and forget about ever getting it wrong again.
- brian-armstrong 3y agoThat doesn'f fix the ugly diff spam though
- junon 3y agoof course it does, why wouldn't it?
- brian-armstrong 3y agoWhat? How would it? Do you understand what is meant by that? The problem being referred to here is that a change on one line causes changes to unrelated lines. It makes it harder to pinpoint which line was changed intentionally in a diff and which ones were just caused by tab issues.
- junon 3y agoErr, yes, been coding for a while :D If you format before every commit, then the only changes you get are the changes you made.
- brian-armstrong 3y agoDoesn't help if you squash changes before merging, which is typical for large codebases
- junon 2y agoAgain, this makes absolutely no sense to me. I've never experienced any of the problems you're facing and I can't imagine how they'd even cause problems.
- brian-armstrong 2y agoIt's not clear why you're still defending this position. Feels like you made a not well considered, off the cuff remark about something. Rather than realize you were wrong and take the L, you're still doubling down? Is it that important to you?
- cqqxo4zV46cp 3y agoThat’s what ignored revisions are for.
- brian-armstrong 3y agoThat doesn't help the problem here. Part of the revision is still relevant (say, adding a new, longer field name to a struct) and the rest is just extra spam. But you wouldn't want to ignore the entire revision.
- junon 3y agoIt really sounds like you've not tried formatters before.