Comment by unholiness | Hacker News Reader

Comment by unholiness | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com