The most important is that the method name reflects a behavior. You do this perfectly well with the
Set prefix (if your project indeed doesn’t use lower camel case for method names).
The consumers would then write something very unambiguous and self-documenting:
If as a consumer I read your interface, it is clear to be that the parameter name reflects the target state that results from the operation:
SetLock (boolean isLocked):
For the maintainers, the name of the parameter will probably be understood the same way. You just should avoid any confusion with the internal state of your class. In the implementation, it all depends. the following seems clear:
internallyLocked = isLocked;
But it is true that the following could appear ambiguous:
Now, if you’re perfectionist, the problem with is not so much the ending of your parameter but its beginning. In all objectivity:
- if it starts with
is, the end should be locked for the sake of grammatical consistency
isprefix suggests a current state. If you want to avoid any potential ambiguity, you could use another prefix that is more clear about the intent and reflects a change of state or the target state.
The exact choice of wording is opinion based. For example:
toBeLocked (target state clearly expressed) or
willLock (change action clearly expressed). But there are certainly many other possibilities that comply with these basic principles.