[hmigneron]

I enjoyed this article a lot because this is a problem I struggle with often when coding. And not just at a particular point in the lifecycle of a project, it comes up all the time.

Decisions like this are, in my case, heavily influenced by how much I trust the rest of the codebase. Having "magic" code on top of a rock solid abstraction feels nice and safe. When I debug / troubleshoot I don't feel the need to step into the function to look at its implementation one more time.

I am much more likely to be explicit, suck it up and write the boilerplate code once again in a messy codebase where the abstractions change all the time (whether I'm the one who wrote the sucky code or not). In the end, I feel like it comes down to how well your objects / concerns are designed. When the concerns are properly separated and your objects are solid, magic code is indeed beautiful and extremely expressive.

[psyc]

I find this is the best way to achieve the balance people are looking for. I try to spread the explicitness across the abstractions, so that it doesn't feel too heavy at any one level. For example, I get a lot of mileage from succinct, least-surprising / 90% case methods that in turn call fully parameterized versions of themselves.