Earlier quoted context omitted.
Unfortunately, ternary operators eventually end up like this due to refactoring blindness: usefulMetric = wantComplexCalc ? (complexity > 40 ? superComplexCalc(foo) : regularComplexCalc(foo)) : simpleCalc(foo);
At some point you have to rely on policy and not language constraints. I submit that no language is constrained enough to protect against refactoring stupidity while also being flexible enough to be useful to the average programmer on the average project. If not ternary if, it will be something else. So, do you throw out every alternative method to accomplish the same thing, or do you put policies in place to keep th…
I believe part of learning a new library/framework/language is to limit yourself to a certain subset of the API offered. After working with Ruby (the language) and Javascript (the ecosystem), I feel like that's the only way to preserve your sanity and productivity. I don't need to know 4 different ways of creating a lambda in Ruby, selecting 1 that can express the other 4 is good enough.
---
In this case, the rule would be no ternary operators, since they work well unless you nest them or unless you make them long/complicated.
Other examples -
You don't need to wrap if conditions unless you have a multi-line body:
if (myCondition)
x = 42;
y = 23;
Early returns simplify short circuiting logic unless your function becomes too long: if (myVariableAtBeginningOfFunction) {
return true;
}
...
// 2 screens later
...
if (x == 42) {
return false; // why am I not getting false?!
}
Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy: if (person.isStudent) {
showSchool();
}
if (person.age) {
showBirthCertificate(); // what if age is 0?
}