4 ms·
Implicits are great. People unfortunately go to great length to avoid typing function parameters so will do all kinds of shit to reduce arguments in function c
by bad_user 8y ago
Implicits are great.
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.
- forkerenok 8y agoI 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 :-\
- pjmlp 8y agoThat is human psychology at work. Usually the rules like these, LOC written, bugs closed per month tend to promote gamification around them.
- piva00 8y agoExactly, I always remember Goodhart's Law [0] whenever I see metrics popping up as goals, be it for OKRs or as guidelines for coding. [0] https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- mlthoughts2018 8y agoI 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.
- forkerenok 8y agoI'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.
- couchand 8y agoWhat do you mean by "f.x."?
- anchpop 8y agoI think "for example"
- forkerenok 8y agoMy apologies, never realized I had this wrong. I think I got this from Danish. It's indeed "e.g." as a sibling comment suggests.
- mlthoughts2018 8y ago
- ljm 8y agoI'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. I find it infuriating.
- wtetzner 8y agoYeah, and the fact that Scala has named parameters means that call sites with a bunch of parameters isn't the problem it is in a language like Java.
- paulddraper 8y agoAnd 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.
- jjtheblunt 8y agoalso agree that best practices are presumptious nonsense.