> 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.
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.
Edit: formatting.