> Do you mean linters that enforce maximum line widths? That seems increasingly rare these days.
Yes, that is what I mean, and I see it more and more because some think passing a linter test will make your code good.
Good point. I was careful to say "big" as well as "multi-purpose", because I think most of us are more comfortable with "big" commits than "multi-purpose" commits, and a commit that is both should send off red flags.
Specifically, it's hard to code review multi-purpose commits because you have to think more extensively about the side effects, risks, regressions, etc. for unrelated changes that are lumped together. If it's a small commit, that tends to not be an issue, but if you're touching several unrelated areas in a big commit, it gets really tough. And as a general best practice, you want your code to be easy to review.
Who thinks this?
> A couple of those points could be boiled down to "use a strict linter with most of the rules turned on".
Now I'm not so sure.
I've rarely seen cases where abstract short variable names have improved readability on their own.
Where it has helped, either there is a comment explaining what the variable is for, or there is a strong convention already in the domain, like using x,y,z in graphics programming to indicate position.
Also... I haven't really encountered linter issues with longer variable names. Do you mean linters that enforce maximum line widths? That seems increasingly rare these days.
> "Commit daily,... . Give meaningful commit messages." I am starting to see a trend where PRs get squashed into one commit. Thus making such advice not very useful.
As a general point of practice, squashes should merge together into semantically meaningful packages, and big multi-purpose commits are the actual no-no. So for example I'll squash together two commits that say "Fixed ABCD issue by doing XYZ" and "Fixed accidental regression caused by XYZ" to just the first message. The fact that I also needed to fix a regression is fine being documented in the bug tracker only, since someone looking at a commit diff will spot the extra XYZ related changes anyway.