In JS (and in any expression-inside-html front end framework) this leads to the hugely common bug

    if (this.finished) { ...

or

    <div v-if="showMainContent>...

With your convention, these could easily be functions, but they are never evaluated without parens. Nor is any error thrown. Instead, the fact that the function exists is truthy and you get the true case always.

In our teams's js code we even include "get" for "is" properties (getIsEnabled() rather than isEnabled()) so that it's perfectly obvious if you're ever using a function without calling it.

TypeScript will produce an error when using a function inside and if stmt without calling it:

    function f() {}
    if (f) {}

produces:

    This condition will always return true since this function is always defined. Did you mean to call it instead?(2774)

https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABMA...

It seems that a linter tool would catch this even if TypeScript isn't used. In any case even if "get" is used, a coder might accidentally write

if (getBooleanProperty) { ... }

omitting the parens.

Except it's also likely, perhaps more so, that `this.finished` is `undefined`, which results in fundamentally the same problem but in the opposite direction of truthiness.

In which case I still see it as just a personal preference. The prefix of "is" becomes reassurance that something is intended to have a boolean value, which may be more important.

Of course it goes without saying that both of these things are (usually) addressed by a system like Typescript.

This isn’t a problem if you use getters.

If the property/field is also writable, that would break symmetry with temperature() vs setTemperature()? How do you deal with that?

Some people feel that symmetry in names is important when achievable, since it makes them more predictable and the entire API more easy to figure out.

The situation is symmetric if there's just a getter and a setter for a state variable, but perhaps sometimes temperature() does a measurement and there's no way to set it because it isn't a controllable quantity (for a thermostat I can set my desired temperature but it will take time for the room to warm or cool to that temperature).

original author here:

That's valid and maybe I'll update the guide to explain a bit more when/where I have found getProperty() useful:

I often do it when I end up having to have parity in API request: a get AND a set. If there's more than one thing i'm doing with temperature, it's helpful to show WHAT I'm doing with it, specifically. I'll noodle on your thoughts a bit and see how I can incorporate them.