On Jun 12, 2019, at 8:24 AM, Michael Jones <michael.jo...@gmail.com> wrote:
>
> Bakul, these are good points.
>
> On the second, I used to always write (C/C++):
>
> If (things are good) {
> happy case
> } else {
> sad case
> }
>
> so the nesting was that the all-good was the first code block even when
> multiply nested and the exceptions came later. A blunt kind of literate
> programming that wants to talk about the 99% case first and the weird things
> later. In Go I've converted to talk about problems all the way to the bitter
> end and then when you run out of problems, do the job. Now that you point it
> out, "else" falls by the wayside in this situation because it is else when
> you did not return already. Each Go-style if-err-die "clause" is consuming an
> else. Thank you. I had not thought of it so clearly.
It's just a different style. Here you are chopping off "sad cases" until
you are left with the big fat happy case! And by returning ASAP for the
sad cases, you reduce indentation quite a bit, which helps readability.
>
> The first is a good point too. The debate about the ternary operator might be
> better viewed as a completion of short variable declaration. Block scope
> means is not possible to write...
>
> if b {
> x := 1
> } else {
> x := 2
> }
> :
> use X
>
> ...so the benefits of short variable declaration are lost to a choice between
> redundancy as you show:
>
> x := 1
> if b {
> x = 2
> }
>
> which hides the intent -- the if b is the intent and that's not evident from
> x := 1. The intent is "x := either 1 or 2 depending" and that is well
> expressible only when the := is in the outer scope and the "1 or 2" are
> expressions from an inner one being transported across the lexical boundary
> by an operator -- the "depending" operator whatever its name or form might be.
You can almost speed-read straight line code but as soon as you
encounter if or switch (or other control flow changing part) you
have to stop and regroup. This is why (for me)
x := b? 2 : 1
is far easier to read than either
var x int
if b {
x = 2
} else {
x = 1
}
or worse,
x := 1
if b {
x = 2
}
> x := {1,2}[b]
This requires evaluating both alternatives. This may not
even be possible:
x := p == nil? 10 : p.val
or may had extra side-effects:
x := {f1(), f2()}[b]
This can also a problem with
x := f1()
if b { x = f2() }
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/94BE2E16-59A0-4984-8D47-E2D3B28E6C98%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.
