Roger, here's the same thing, but for Russ's corpus v0.01:
https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8
I've been comparing the two side by side and it's fascinating.
Bakul, more good arguments. I have another motivation in the "?" world that
I've not argued because it is personal/not general, but a decade ago I had
two detached retinas, surgeries, and imperfect recovery. Part of my vision
that I lost is just below the center...maybe -15 degrees to -40 degrees.
The brain knows when I want to see things things there and moves the eyes
around to gather that part of the visual field. This "hunting" is tiring of
the muscles and causes issues. left-to-right density is easy for me,
vertical is very bad. Your:
x := b? 2 : 1
is instantaneous, a sight read; while the:
var x int
if b {
x = 2
} else {
x = 1
}
and
x := 1
if b {
x = 2
}
...feel like climbing Everest. It is hard to explain the difficulty.
Fortunately it is not a widespread problem. Certainly not Go's problem, but
I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
= 2 } else { x = 1 }". In fact, now that i've just seen this, I am going to
make a local version and hook it to vs code. Why did I not think of this
before! Wow.
On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah <ba...@bitblocks.com> wrote:
> 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() }
>
>
>
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
