'best practice' is a difficult concept when it comes to naming things, which is one of the two hard problems of computer science.
However, I agree with ariel. In a functional-style program, or indeed in most programs, the important thing about a function is what it returns, not what it does. Calling a function 'getRandomNumber' describes the action of the function, not the return value, which is just 'randomNumber'. As your example shows, the logic in English flows much more naturally with the latter.
It's much better to talk about the box.size, rather than the box.getSize, for example. To me, the presence of 'get' in a function name is almost always a bad idea.
Similarly, I normally use the word 'as' rather than the word 'to' when naming conversion functions, e.g. list.asArray, rather than list.toArray
With setters, you're implicitly working in a mutable world, at which point it makes sense to name it for the action, so I think you have to use 'set'. So I would have x() and setX(), instead of getX() and setX().
In an immutable world where you're making a copy (perhaps even through a lens), then I often use 'with', e.g. myNewObject = myObject.withX(12.0).
I guess on many occasions, the get/set could also be avoided by thinking about the usage a little deeper. Take HTTP frameworks for example:
getHeader()
setHeader(key, val string)
could also be defined as:
requestHeader()
responseHeader(key, val string)
I must admit I'm someone who, despite best efforts to give meaningful and consistent function names, often ends up with something less standardised by the time projects start to grow, deadlines loom and fatigue sets in (I'd imagine this is probably true for most people - if we're completely honest). But it's always good to get (if you pardon my pun) reminders and advice about sane naming conventions.
Yeah, naming things is hard. Harder than most other things. There's always trade offs and it's heavily dependent on personal preference.
That said, I think your ideas here are good. 'Get' and 'Set' really don't convey that much information, whilst your code above makes it clearer what is going on.
I like 'xIs' for mutators, because it reads more like English, and the important part of the name ('x') is first. I find that convention makes it easier to scan code by name and sort.
Some languages provide you with a mechanism to deal with that (c#s properties), and many others allow you to get a similar result with function overloading. So you don't have getX() and setX(), you have X(), and X(int x)
While function overloading is a neat trick, I think it's a step backwards in terms of code readability.
In those instances, it's only clear from the usage rather than the name how that function behaves, so I think I'd rather see getX and setX over X() and X(int x) and be absolutely clear about the role of that function.
However, I agree with ariel. In a functional-style program, or indeed in most programs, the important thing about a function is what it returns, not what it does. Calling a function 'getRandomNumber' describes the action of the function, not the return value, which is just 'randomNumber'. As your example shows, the logic in English flows much more naturally with the latter.
It's much better to talk about the box.size, rather than the box.getSize, for example. To me, the presence of 'get' in a function name is almost always a bad idea.
Similarly, I normally use the word 'as' rather than the word 'to' when naming conversion functions, e.g. list.asArray, rather than list.toArray