3 ms·
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 woul
by NickPollard 12y ago
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).
- laumars 12y agoInteresting. 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.
- NickPollard 12y agoYeah, 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.
- mfichman 12y agoI 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.