I agree that ? for simple choices is nice. But my C experience with nested
?s and with long expressions for one or both branches has not been nice.
The mandatory {}s make Go's nested ifs more readable (but vertical).On Wed, Jun 12, 2019 at 2:42 PM Michael Jones <michael.jo...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAOUkXSqPpaw7h99ugzO8tL26sA8e_6oPZtiwHCb5Y3BrNC0QYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
