I wouldn't say that best practices drive people to doing stupid stuff, at least not directly. And they usually do have merit.
The issue is that people apply them without understanding the motivations behind.
F.x. the "too many method or constructor args" warning signals that a class or a method is probably doing too much, so please decompose. A person without understanding the motivation will think it's a sort of a game and wrap some params into a map or move some them into globals :-\
I find it insane that someone would use an actual lint rule to enforce a best practice about few function parameters (loosely defended by this thin complexity argument).
Functions of appropriate complexity routinely have more than 3 arguments, even in standard library functions.
Why not just use common sense and code review? If a certain function actually needs 10 arguments for customization (for example, this is common in plotting libraries), so be it. If during code review the writer can give a reasonable account of why the complexity is useful, then just move on.
I cannot see any way to defend putting this is a linting rule.
I'm not a fan of those either (and 3 arguments is insanely low indeed), but I see a way it can work: you always have a choice to suppress a linter finding if your case is "legitimate".
F.x. in our case the limit is 7. I think most people would agree that 7+ args constructor or method is worrying. But there are cases where it can be ok (with or without some stretch), f.x. if it's some sort of a glue code that does a very mechanical thing and breaking it down would be nothing short of gold-plating.
Edit: In general I find the signaling that linter gives useful. At the same time I agree that mature teams can do without it just fine.
Yes, but then you just encourage people to litter the code with noisy linter suppressing directives or comments.
The point of directives that suppress specific linter rules is that it should be used in rare, exceptional cases when an otherwise common lint rule needs to be violated.
But having a large number of function parameters is not rare or exceptional: you have that for legitimate reasons all the time.
If a lint rule causes lint overrides to become a daily experience, I’d say that clearly tells you that the lint rule itself is wrong, not the software practices.
To me, someone who would support a lint rule reducing function parameters would almost certainly be someone who had a deeply unpragmatic and unrealistic obsession with certain kinds of design patterns and refactoring patterns.
You code professionally long enough and you start to realize that most design patterns, especially OO cookie cutter patterns, are pretty crap and only have a few narrow use cases.
Introducing some type of abstraction purely to allow refactoring into function signatures with fewer parameters would be a nasty bad code smell to me.
> But having a large number of function parameters is not rare or exceptional: you have that for legitimate reasons all the time.
That doesn't match my experience. IME, virtually most cases where I've run into asignaturas with more than about 3 parameters, there have been one or more groups that should have been passed to another function whose result should have been passed to the present function.
But that may be context dependent.
> If a lint rule causes lint overrides to become a daily experience, I’d say that clearly tells you that the lint rule itself is wrong
Sure, so in a context where you need to do that daily, the lint rule is bad for that context.
> But having a large number of function parameters is not rare or exceptional: you have that for legitimate reasons all the time.
I think here we can only speak of our own experiences. In my team's experience that linter rule had been triggered only 2-3 times in 2 year history. Far from being "daily experience". And in all cases it was warranted: it was a poor choice of abstraction that resulted in accumulation ever-growing number of dependencies in a class.
> Introducing some type of abstraction purely to allow refactoring into function signatures with fewer parameters would be a nasty bad code smell to me.
Referring to my earlier comment, the point is not to blindly refactor something to satisfy the linter, but to actually understand:
* is there really a problem (in _your_ terms) behind a given linter signal?
* if there is a problem - fix it
* if not - well, suppress it for this instance, adjust or get rid of this linting rule.
> You code professionally long enough and you start to realize that most design patterns, especially OO cookie cutter patterns, are pretty crap and only have a few narrow use cases.
When it comes to OO patterns I tend to agree: many are quite narrow and the way they are pitched ends with people looking for nails with a bunch of hammers. I.e. people keep "applying patterns" instead of fixing problems in their code. But those kind of linting rules are not about design patterns.
The issue is that people apply them without understanding the motivations behind.
F.x. the "too many method or constructor args" warning signals that a class or a method is probably doing too much, so please decompose. A person without understanding the motivation will think it's a sort of a game and wrap some params into a map or move some them into globals :-\