I prefer the get prefix only for getters. For something like getArea that is doing more than getting (even if cached), I prefer calc as the prefix.

Some naming conventions use void radius(float) and float radius() const for setter/getter, others prepend set and/or get. This follows the guideline to make the code read like English: car.setGear( Gear.Drive ) means “Hey, car, set your gear to Drive.” vs. car.gear( Gear.Drive ) is a setter or a query or installing a new gear or something else?

I go back and forth on this idea for reasons like VK and Alf list.

Tool support is not a trivial concern, and it’s not obvious that the IDE experience could be as useful with free functions that are packaged with a class — i.e., it’s not just a problem right now and that the tools could catch up, but rather that the experience cannot be as good because they just don’t know.

Uniform call syntax could make this a little better because it would allow IDE-friendly lookup when calling x.f(), but it still won’t help if one wants to use the equally valid f(x). Maybe uniform call syntax means we start to prefer the former for this reason, among others?

I do agree with VK. Just to add more on his point 3, we should follow Interface Segregation Principle. However, putting all virtual methods in one interface is definitely not a good idea. We should try to separate them as much as possible. For example in the above class, we may have following interfaces.

class IShape {
// generic methods pertinent to all types of shape object
virtual void getArea() = 0;
virtual void getPerimeter() = 0;
};

class ICircle {
virtual void getRadius() = 0;
// any other methods that is related to circle like objects
};

Wow thanks Vlada for taking the time to express such a detailed opinion. I find your points valid and very interesting. What you’re sharing makes for a much richer view on the whole topic.

Do we agree that the uniform syntax would solve most of the concerns you’re raising on the Interface Principle?

Yep you’re right Michael, it’s now fixed. Thanks!

I, personally, use “get” prefix to emphasize that the function/method really “gets” something, e.g. retrieves something from db, performs heavy calculations, etc etc. If it just returns private “int radius”, I just name it “radius()”

Thanks Theldoria, well spotted. This is now fixed.

2) It
violates the “least surprise” principle. I do not know how other
programmers feel about this, but I find the fact that getRadius() is a
method and getPerimeter() is a free function extremely surprising! How
are they different? Is radius more important than perimeter? Is there a
logic in this decision? Oh, yes it is. But it is solely based on the
implementation detail which is that you, by chance, decided to store the
radius as the class private member. If you had stored the perimeter
then the public interface would be different, wouldn’t be? So you are
indirectly exposing you implementation details as a burden to your
users. What if in the future you decide to change this implementation
detail?

3) Design! Design! Design! General design
should drive your decisions. Maybe this was just an artificial example,
but you will not probably make a software dealing only with circles. You
will more likely make software dealing with shapes and circles will
only be one of the many shapes you will be able to work with. So you
will have some interface (abstract class) Shape (or IShape if you will)
and will design its interface. Would you add getRadius() into this
interface? Definitely not because it relates only to circles. Would you
put getArea() in this interface? Oh yes! Of course, every well behaved
shape should have some area. So this is what should drive your interface
design. Not the fact that you decided to store the radius to
Circle::m_radius and then base all other decisions on this one.

Overall I think this article is extremely confusing for beginners.

“calls f(x, x1, …, xn) if f is a method and not a free function”

actually be:

“calls f(x, x1, …, xn) if f is a free function and not a method”