3 ms·

Mostly good but I hate getProperty names. If a method returns the temperature call it temperature() not getTemperature(). If the private data member has to have

by not2b 5y ago

Mostly good but I hate getProperty names. If a method returns the temperature call it temperature() not getTemperature(). If the private data member has to have a different name, _temperature or some similar convention will do.

unholiness 5y ago
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.
- ravenstine 5y ago
  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.
- emptysea 5y ago
  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/GYVwdgxgLglg9mABMAFASkQbwL4CgbCIrAY5A https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABMA...
  - not2b 5y ago
    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.
- JimDabell 5y ago
  This isn’t a problem if you use getters.
unwind 5y ago
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.
- PostThisTooFast 5y ago
- not2b 5y ago
  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).
paceaux 5y ago
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.

by not2b 5y ago

unholiness 5y ago

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.

ravenstine 5y ago
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.
emptysea 5y ago
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/GYVwdgxgLglg9mABMAFASkQbwL4CgbCIrAY5A https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABMA...
- not2b 5y ago
  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.
JimDabell 5y ago
This isn’t a problem if you use getters.

unwind 5y ago

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.

PostThisTooFast 5y ago
not2b 5y ago
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).

paceaux 5y ago

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.