Explicitness, verbosity and their counterpart - when to prefer which?

Question

I'am the only one in my team who advocates for adding a little implicitness in favor of codebase reduction and decreasing repetition. Yet I don't want to be a biased 'Bad apple' playing against working design which was created prior my arrival at this job. Attempts to change the approach can be taken too personal by some teammates and just saying 'mine is better than yours' promisses the opposite result.

Trials to find cons of the proposed and pros of existing solution are the best way to fight against biases - so called 'devil's advocate' game. Unfortunately, it's quite diffcult sometimes.

The broad question sounds like this:

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection.

The narrow question is quite local, nonetheless I dare to ask for the list of pros and cons of both approaches.

Our server application has several layers: Service, Business Logic, DAL.
For any data modification (create+update, no deletes) we also save authenticated user stamp thus havig the history who did what.

Current implementation gets user name from framework MVC/WCF and passes it across the layers as an additional argument to the methods just to pass the value to the next layer until it reaches the session object which manages the transaction. (DAL)

I offer to use AmbientContext approach: Userstamp is set once at the very beginning of the request processing pipeline and then implicitly flows with execution workflow (respecting async) and is accessible by any layer if required. Very similar to Thread.CurrentPrincipal.

Answer 1

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection.

Not many.

The first is the Law of Demeter, which focuses on how many "steps" it takes to get to what you want, which directly relates to your question about indirection.

Another is Tell, don't Ask. If you have some implicit state being carried throughout the program, objects necessarily need to ask about the state rather than being told about it.

Otherwise, it depends...

It is generally accepted that explicitness is better than implicitness. And your example question brings up other soft metrics: code coverage, bug count/severity, and team velocity.

If by making things implicit, you make it difficult/impossible to unit test your code, that is a fairly clear cut downside.

If by making things implicit, you cause there to be more bugs or more severe bugs (possibly due to worse/fewer unit tests? concurrency/reentrancy issues with the implicit state?) then that's a fairly clear cut downside.

If by making things implicit, you make the team produce code slower (harder to write unit tests? Harder to read? More time spent fixing bugs?) then that's a fairly clear cut downside.

And of course the opposite can be true - if implicitness allows you to make more code, with fewer bugs, then the positives are there. Like all other program design, it's a matter of trade-offs.

Answer 2

You are asking two very different questions. The former one is not a generalization of the latter, because answering the first won't answer the second.

There are many other things that might influence the second question, like how you would tackle transactions with multiple users and such.

As for the first question, everybody agrees that a shorter solution to the same problem is preferable, provided it can also be understood. There is no absolute guideline for that, since understanding is subjective. Use code reviews to find a sweet spot that works for your particular team.