@SergeyZolotarev oh sure, ever rule has an exception. But ignoring the rule comes at a cost. Be sure you want to pay it rather than think of something better.

Jump is the worst example, because in natural language it may have a noop post-condition (jump in-place by default). I request an example with "jumpDown()" or "jumpOut()"

@Caleth noop post-condition for a method without return value makes no sense.

@Caleth What return value do you require from updateUI() method and why? It may leave old values in place if they match new. User does not care whether the actual UI event happens.

Let us continue this discussion in chat.

@Steve random speaks to nondeterministic behavior which can be a very bad thing. But unknown behavior from the callers point of view can absolutely be a requirement. Stop insisting on knowing everything. Let something else deal with it.

@steve insisting on knowing every detail of what’s going on all at the same level of abstraction is a procedural programming habit. Pushing details behind abstractions where you don’t have to think about them is more object oriented. It’s also less coupled. It is entirely possible to get the details the caller deals with down to simply “do it now”. No returns. No exceptions. Just do it now and leave me alone. The name for that level of coupling is “event”.

@candied_orange your point would be even better communicated if you just post the last message from chat - "the natural language from method name does not establish postcondition contract". Because you argue that methods can be configured to do nothing, I argue, that natural language communicates that method promises something and we are at impasse.

@Basilevs well hang on. Natural language certainly can promise something. I definitely would prefer names that did that over methods named after Simpsons characters. But reality and configuration can break that promise, even silently. That silence can be required. Communicating the promise well is a good thing. The problem is thinking you can rely on the promise despite everything else. No promise is that strong. When you understand that the "try" prefix feels redundant. Are we still at an impasse?

@candied_orange internally method can do whatever. But external observer should see expected result. If (observable) promise is broken, the method name is incorrect. Introduce a new method with new contract/promise and a different name.

@candied_orange remember LSP - similar principle applies. Any method implementation is allowed as long as it behaves to contract.

@Basilevs yes but configuration can replace contract. The null object pattern is proof. Yes client A needs service A to follow contract A. But then someone changes everything to be B’s that use the same interface with a different contract.

@Basilevs why is it a contract for logging can silently do nothing when so configured but nothing else can unless you put "try" in its name?

@candied_orange neither null object nor log interfaces have observable post-conditions for clients, so they are fine.

@Basilevs null object is meant to be swapped in for something that does have observable post-conditions. It's simply a special case where the observable post-condition is a whole lot of nothing.

@candied_orange that's my point - if no postconditions are observable, method can do whatever it wants.