People unfortunately go to great length to avoid typing function parameters so will do all kinds of shit to reduce arguments in function calls. This includes all kinds of insane dependency injection frameworks that depend on runtime introspection or bytecode manipulation, or stateful objects being passed around instead of plain values.
There's even this best practice around that says "have functions with 3 params or less" which is complete bullshit. I mean, you actually have company wide policies with enforced lint rules on maximum number of params and people end up passing around giant records (maps, objects) that then get unwrapped.
I cannot blame implicits, if anything, if people are going to go to such great lengths to avoid passing arguments in functions, I'd rather see implicits instead of Spring or Guice, because at the very least implicits are compile time.
The actual cancer are the best practices that drive people to doing this.
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.
I've felt similar after seeing the rise of Rubocop after Sandi Metz did some talks and wrote a book about object oriented design in Ruby.
Her advice is totally sound, if you hear her out she does not advocate for the dogmatism that had since infected the community (and the linting tools...).
Yet still, you will work for a company who insists on a hard and fast rule that a method cannot be more than 10 lines long. Or a class cannot contain over 100 lines.
It's not on the same level as implicits and everything else Scala lets you do, but still...it makes code worse.
Your 11 line long function that is perfectly readable has to become a shorter function that calls other methods that wrap the same logic, but are otherwise not useful in any other context. Or you have to fuck with the syntax to reduce the line count.
You end up with code full of indirection because the community decided to quantify readable code and build policy around it.
And even if you really do want to have "X params or less", Scala makes it really easy to achieve with case classes. Group your parameters into data classes of X parameters or less, and viola, you have reasonably succinct, readable solution.
People unfortunately go to great length to avoid typing function parameters so will do all kinds of shit to reduce arguments in function calls. This includes all kinds of insane dependency injection frameworks that depend on runtime introspection or bytecode manipulation, or stateful objects being passed around instead of plain values.
There's even this best practice around that says "have functions with 3 params or less" which is complete bullshit. I mean, you actually have company wide policies with enforced lint rules on maximum number of params and people end up passing around giant records (maps, objects) that then get unwrapped.
I cannot blame implicits, if anything, if people are going to go to such great lengths to avoid passing arguments in functions, I'd rather see implicits instead of Spring or Guice, because at the very least implicits are compile time.
The actual cancer are the best practices that drive people to doing this.