4 ms·
"auto a = ConjureMagic();" "SetMagic(a);" The problem here is actually is an old one of failing to separate a getter from a command. It looks like ConjureMagi
by nercury 11y ago
"auto a = ConjureMagic();"
"SetMagic(a);"
The problem here is actually is an old one of failing to separate a getter from a command.
It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to.
This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better name, like "GetMaxMagicPossible". That renders an auto no longer confusing, because this name explains more than the return type. If, on the other hand this is just a command to conjure the magic and we are getting the remaining amount only to immediately pass it to the member "SetMagic" function, then there was no point in returning this value - it could be done inside the "ConjureMagic" itself.
- takeawayandrun 11y agoHaving Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conveying the const'ness is important as you describe (or semi-constness if you have caching)
- zeta0134 11y agoI'm of the somewhat unpopular opinion that "getters for everything!" is a philosophy that sounds good on paper, but results in writing a lot of getter and setter functions and feeling safe, while ignoring these sorts of traps cropping up everywhere. Member variables are easy to reason about; they behave exactly like the type they are, and in the case of built in types, have extremely consistent behavior. Getters / setters are a black box of mystery; I like to reserve that pattern for when there's going to be extra work to retrieve some value, so my call site knows it needs to tip-toe around possible failures. While I can see the value in using getters/setters for everything in something like an API or framework, I don't see the value in trying to use them all the time, "just in case."
- ta0967 11y agono, having getters for each member variable is a sign of pervasive action in distance and lifetime problems.