[ljm]

Not for the same reason as you, but to me 'best practice' means that you can't do any better. In this context, it's saying that if you do it any other way that this specific way, it's objectively worse.

I prefer 'good practices' or 'guidelines' but as far as something like Rubocop is concerned, I don't really agree that its default setup meets that standard. Without some careful tweaking of the configuration you're likely to end up with a codebase full of premature abstractions that exist for literally no other reason except to satisfy Rubocop.

There is a subset of Rubocop rules that does a much better job, in terms of identifying potential sources of bugs (e.g. calling non-TZ aware date objects) and replacing deprecated methods with their alternatives where possible. The tool is worth it for that, so long as you disable all the nonsense about method lengths, class lengths, number of methods in a class, etc.

[bitwize]

"Best practice" in software, near as I can tell, means "what you will not get fired for doing". It means adhering to rules that the community has adopted, irrespective of whether those rules are a good idea even in the general case, let alone a specific instance where it might be better to contravene conventional wisdom.

[willcipriano]

> calling non-TZ aware date objects

That's a great example. What if I'm working in a embedded system with limited memory and I need to shave off a few kilobytes? What if time zones don't matter for my implementation, say I make a timer app and the only thing that matters is the delta between two times?

There are things that I think rise close to the level of best practices. For example your password hash comparison function should probably run in constant time, but a linter is never going to pick up on something like that.