Quoting robert engels (2018-11-24 17:34:34)
> Agreed, but that is why I have a big problem with variable inference as used
> in Go (and now Java 9 with var).
>
> You need to refer to the callee API doc in order to gain understanding of the
> code - as the type information is not readily available. Even though there
> are less characters, so people claim - easier to read - the loss of
> information when dealing with non-common methods is a huge loss in
> readability/understanding IMO.
Having spent a lot bit of time working in languages which don't require
writing as many types, either because they can infer them (like Go, or
to a much greater extent ML-family languages), or because they just
don't have them (Python), I've found well-designed APIs make the absence
of this information at the call site not much of a problem. Designing
for the call site is a good idea in any language. What that entails may
vary based on the details of the language itself. It always at least
involves good names; errors.New is pretty self explanatory. This:
var err error = errors.New(...)
..is just noise.
> I find myself continually reviewing the documentation when reviewing
> Go code - much more so than Java - with external frameworks, etc.
If I'm doing code review and I have a hard time understanding it, I usually
ask the author to fix the code.
If you have control over the callee API it can take the form of improving
that, so that the call site is clearer. Sometimes a simple comment will help.
Sometimes that means just putting the type annotation there even though you
don't have to. This is common in ML family languages, where type annotations
are never actually required *anywhere*. All language features are abusable.
-Ian
--
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.
For more options, visit https://groups.google.com/d/optout.
