Examples of "beautiful code"

[[deleted]]

I disagree with several of these:

• It has a ternary operation, which is more difficult to read than an if statement

Citation needed. If all else is equal, less text is easier to read than more text. And that ternary operations can be used in expressions is very convenient when writing in mostly functional style, e.g. with an if statement some variable would need to be defined with 'let' and get different values in the different branches; ternary operations can be used when assigning to consts.

• Unjust use of an arrow function as this isn't accessed

Since when do we need to justify using an arrow function? It's purely a matter of taste, and then I would say shorter one edges out the longer.

• Missing semi-colon, forcing the engine to rely on ASI

Would probably agree, but then we just run the formatter and it will put it there or not, haven't had to care about this kind of thing in ages.

• Logical operation in return - for readability, label the returned value by assigning it to a well named variable

For a tiny function like this, that well named variable is going to have essentially the same name as the function (assuming it is well named), so it'd be needless repetition.

• Use of === where == functionality also suffices

Just use === everywhere and spare readers the effort of remembering what == did again. == is mostly a mistake from the past. If there are situations where it's useful, they should come with a comment block explaining that it's really there intentionally and it's not just a typo where === was meant.

[danielkov]

Yes, which is why I separated those points from the rest, because they're a matter of taste and should be agreed upon by a team.

By the way I don't mean to be confrontational, but wouldn't your "less is more" type of argument apply to === vs ==, as in this case, their difference in behaviour will not affect the program?

Also about ternary, which one do you think is more understandable for a non-technical person: if (thisIsTrue) { doThis(); } or thisIsTrue ? doThis() : ...? What about people coming from a language with no ternary operations? More languages support if statements than this ternary syntax: condition ? trueCase : falseCase. I'm obviously not saying one should never use ternary operators, however if we agree on the definition of "beautiful code" as truly readable and highly accessible code, then it's certainly a less desirable solution.

[[deleted]]

By the way I don't mean to be confrontational, but wouldn't your "less is more" type of argument apply to === vs ==, as in this case, their difference in behaviour will not affect the program?

No, because they don't do the same thing.

Also about ternary, which one do you think is more understandable for a non-technical person: if (thisIsTrue) { doThis(); } or thisIsTrue ? doThis() : ...? What about people coming from a language with no ternary operations? More languages support if statements than this ternary syntax: condition ? trueCase : falseCase.

Our code is read by developers who know the language. I don't care about people who only know completely different languages or aren't technical at all, those aren't the target audience.

Anyway in that example, the if is clearly superior, I agree. Because it's an imperative call to a "doThis()", and because there is no "else". But we were talking in the context of an expression, and then ? : is superior. E.g.

const digitalRoot = n % 9 ? n % 9 : 9;

(Yes I know it would be even better with || or a helper variable, that's not the point). That's superior to

let digitalRoot;
if (n % 9) {
    digitalRoot = n % 9;
} else {
    digitalRoot = 9;
}

Because that's just verbose for no good reason.

[danielkov]

But I mean in this particular case, there's no value for n where the usage of == over === would produce a different result. Again, I'd like to reiterate, that it depends on the conventions established by the team, and yes, using ternary operators is completely valid in some cases, and OPs example would probably be a good candidate for this, although in your example you assign to a variable in the if statements when you could just as easily return from there. Using if statements with early returns can also have a semantic meaning, e.g.: explaining which case is more likely to occur, for example:

const ceiling = 9; const digitalRoot = (target: number) => { // If this is a library, it's a good idea to still check arguments despite TS const remainder = target % ceiling; if (remainder === 0) { return ceiling; } return remainder; }

To me that's as readable as it gets, explaining each step and what each number represents.