|
|
|
|
|
|
by jiaweihli
3436 days ago
|
|
|
In all honesty, I prefer having rules that have no special-case 'unless' issues. It's too much effort/trouble to remember all the cases where things don't work. I'm a good engineer but a terrible compiler. 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?
}
|
|
|
Why not "no nested ternary operators"?
> You don't need to wrap if conditions unless you have a multi-line body
Why not "keep unwrapped if conditions on a single line"?
> Early returns simplify short circuiting logic unless your function becomes too long
Why not "keep functions short"?
> Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy
Why not "only use conditionals on boolean values"?
I'm not saying your rules are right or wrong, I actually follow a couple of them myself, but your wording implies that other people are simply not following rules, or their rules have a lot of nuances and special cases, but the reality is more likely that their rules are different.
Ultimately we all make different connections and form different patterns in our head. As long as a team can agree on a code style, within a few months everyone starts developing the same cognitive patterns.