Hacker News new | ask | show | jobs
by rogpeppe1 2186 days ago
There's no need to use the pointer in there; you could just use an ok bool instead (saving the indirection): https://go2goplay.golang.org/p/4hr8zINfRym

I think it's interesting to observe that using the Result type is really not that much different from using a multiple return value - it's actually worse in some ways because you end up using "Unwrap" which can panic.
1 comments
peter_l_downs 2186 days ago
I like your solution, although it's a tradeoff when the value type is some kind of nested struct whose zero value could be expensive to create.

Agreed that multiple return is actually quite nice in many situations, although `Unwrap()` is generally only called after checking `OK()` and the real benefit is in using `Map()`.

    a, err := DoCalculation()
    if err != nil {
      return err;
    }
    b, err := Transform(a)
    if err != nil {
      return err;
    }
is a lot more verbose and harder to read than

    a := DoCalculation()
    b := ResultMap(a, Transform)
link
codezero 2184 days ago
I happened upon this comment a bit late, and caveat I'm not really a software engineer, but this comment made me think of something...

I've written a decent amount of code professionally in the first and second styles.

I sincerely prefer the second style, for reasons that are hard to articulate, maybe the aesthetic, the space, or something that I assume is equally as questionable.

After I stopped writing a lot of code, when I got pulled back in to debug or provide context long after the fact, in both cases, it was way easier in "real" code bases, to catch myself back up on things in the case that the code was of style 1, than when it was of style 2!

I may be alone in this sentiment, and I even regret that I have it.

I think there is also a bit of satisfaction in writing the code in the second example, especially when the example is a lot more complex than the one provided here.

Maybe it comes down to how much re-reading/maintenance your codebase actually needs. I wonder if coding convention/style has been mapped to the types of problems that code creates and the subsequent repair of those problems being dependent on the code style... I'm sure if I google it I'll find something :)

link