kinda funny...
the talk is precise, touche, and cliche.
Like software engineering 101 from top-notched software companies.
Especially from those top-notched software companies which writing C++ code.
That is, if C++ were not coded in this way mentioned in this talk, the project is just doomed to fail.
But for Go Lang, even you don't coded in these mind sets, the project still works, and maintainable, just that, it's shit code.
Clear is better than clever [pdf]
271–280 of 335 posts
Re: Clear is better than clever [pdf]
#272Earlier quoted context omitted.
I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.
Nested ternary is fine as long as it’s written on multiple lines because then it exactly mirrors the if/else-if/else structure. return ( a b ? 1 : 0)
>then it exactly mirrors the if/else-if/else structure.
But it doesn't mirror the if/else-if/else structure. Rather the mirrored semantics looks as follows:
if(a b)
return 1;
else
return 0;
Is there a functional difference in this example? No. There isn't. Is there a functional difference in any example? I don't think so, but I'm not 100% sure. And the nice thing about not being clever, I don't have to worry about it.
Re: Clear is better than clever [pdf]
#273Clear is indeed better than clever, but clear and clever are not mutually exclusive poles. You can be clear and stupid, clever and stupid clever and clear, all is possible.
Re: Clear is better than clever [pdf]
#274Earlier quoted context omitted.
It's not 10 lines, it's 8. Your implementation would need the function declaration and the } at the end too. Now consider this: return a > b ? 1 : a Or: return a == b ? 0 : a Or: return b Are all these equivalent? Figuring that out is much more difficult than their 8-line counterpart, at least for me. My eyes have to keep jumping from left to right in order to do the checks, like they would do in a piece of uglyfied…
> Are all these equivalent? But is that really what you're looking for? I see that idiom and I think, "Ok, this is a comparator" and I move on. If I suspect a _bug_ in the comparator, then I'll look at it more carefully, but the context is about writing code whose intent is clear, not writing code that can be scanned for bugs easily - which would be a tall to impossible order anyway and isn't made any easier by spraw…
Well that is what I think if it's on the first case I mentioned. I see it contained inside a comp function and I move on.
If I see it "on the wild" (as part of a bigger function), however, my train of thought goes "Wait, why is this piece of code here instead of a function call called `comp`? Is this a comparator or is this something else? Ok geez time to do the javascript eye dancing thing. You know what? I'm just not going to approve this and demand that this piece of code is at least given a proper name and put somewhere. Possibly with unit tests"
Re: Clear is better than clever [pdf]
#275It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.
>We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.
Parchment, no, but do you not value vertical terseness when evaluating a function for code clarity?
Re: Clear is better than clever [pdf]
#276Earlier quoted context omitted.
> You see the problem though, I need to try it and practice it to see how simple and clear it is. You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table. > Why do I want that? To…
>It literally takes 5 seconds to understand the idiom I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. In fact, it is obviously so confusing that to make it work someone s…
> It's still hard to read if you inline multiple ternary operators the way OP suggested is easy.
I disagree. The ternary version is much easier to read than your if-else. If-else statements can feature compound statements and side-effects where the ternary version is simpler because it only returns a value. There are fewer corner cases to consider.
> It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does.
It adds no complexity. It's significantly easier to understand than if-else.
> which isn't quite true. It's actually:
Right, there's literally no semantic difference between those two.
> No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code.
You really don't. There's nothing special to consider, no corner cases. It's literally condition-on-left-value-on-right.
Re: Clear is better than clever [pdf]
#277It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…
I prefer to put it into a function and do early return/guard clauses for complex conditionals:
const pick = (param1, ...) => {
if (cond1) return 1;
if (cond2) return 10;
return 100;
};Re: Clear is better than clever [pdf]
#278Earlier quoted context omitted.
It's becoming more popular. Kotlin, Swift and now C# 8.0 have pattern matching (well, close enough at least). I sure hope other languages take note, because you are right about it essentially being a solved problem.
Scala, too.
Yep! Scala's pattern matching is so far ahead of Kotlin's, vis a vis destructuring, that it strains the conscience to say Kotlin has pattern matching at all. FWIW I find both to be enjoyable languages in which to work.
Re: Clear is better than clever [pdf]
#279Earlier quoted context omitted.
As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.
"Personally, I find that ternary example you posted to be terrible code." It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does. My nitpick would be with the language constructs themselves. The ternary operator is simply a crutch for lack of an if-then expression returning a value. if a b then 1 else 0 Or can add some white space to make the structure a little…
by replacing tokens recognizable as natural language words with arbitrary punctuation
It's far from "arbitrary" --- and I suspect that this dogmatic, misguided way of (not) thinking about it is responsible for the majority of the complaints and aversion, since as others have mentioned, it is completely equivalent in structure to if/else!
What do I mean by "far from arbitrary"? Well... what is the character used in basically all Latin (and even some widely-used non-Latin) languages to denote a question? I've already used that character twice in this post so far, and you should've found the previous two sentences to be pretty clear, so stop pretending the ternary operator is something scary and "unreadable" and see it for what it is: it is literally asking a question!
understand ? done() : keep_thinking();Re: Clear is better than clever [pdf]
#280It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…
Or
if(cond1) myVar = 1;
else if(cond2 && cond3) myVar = 10;
else if(cond2 && !cond3) myVar = 100;
else myVar = 4;