Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Style

google.github.io

Post reply on HN
Print view View original

131–140 of 212 posts

Re: Go Style

#131

Post by abdusco »

whalesalad wrote: post #50
Cthulhu_ wrote: post #37

Earlier quoted context omitted.

This is the answer. Write a utility instead of get frustrated with the language; be pragmatic. Same with looking for libraries that do something trivial.

I’m used to parsing a date time with things like %Y-%m-%d not the asinine way Go does it.

If you're using JetBrains Goland, hit Ctrl+Space when you're writing the date layout in `time.Parse`, and it'll suggest you the regular YYYY, MM, dd etc. placeholders. When you pick one, it types in 2006, 01, 02 magic numbers. Here's a GIF:

https://imgur.com/FyCJZvh

That said, I hate this, all the ways it's opinionated and praised zealously for it as the best thing since sliced bread.

Re: Go Style

#132

Post by monocasa »

thunky wrote: post #40
don_albrecht wrote: post #32

Earlier quoted context omitted.

This advice should be universal in coding. When I first started programming, I had a manager that hated 1-2 character variables. But they make sense for loop iterators.

For loop iterations it's fine, but I think Go code often takes this too far. It often takes longer to read a single character than a word, because I have to mentally map the character to the word anyway. Reminds me of when people go nuts aliasing table names in SQL queries, which IMO makes it harder to read as well.

Exactly.

I think a better heuristic rather than tying it to scope is to sort of semantically huffman encode. Using an iterator is probably the most used variable name that starts with an 'i', so it gets just plain 'i'. As a _concept_ gets more specific, then it gets a longer name.

Re: Go Style

#133

Post by ehsankia »

SEJeff wrote: post #128
don_albrecht wrote: post #32

Earlier quoted context omitted.

This advice should be universal in coding. When I first started programming, I had a manager that hated 1-2 character variables. But they make sense for loop iterators.

Yeah i for for loops (in python) x for comprehensions, etc, make sense. But in general, single character variables make code really hard to read.

Yep, you should just use the best judgement, for example

    for distance, time in driving_metrics:
      speed = distance / time
is a lot clearer than

    for d, t in driving_metrics:
      s = d / t
even if it's used in a tiny scope once. But some things don't have a valuable meaning, or the meaning can trivially be inferred.

Re: Go Style

#134

Post by rand0m4r »

gopher_1234 wrote: post #42

The kubernetes ecosystem has a lot of go code which consequentially suffer from nil panics. Thankfully they recover otherwise we'd see an absolute shit ton of pod restarts. In general, please stop panicking in library Go and Rust code. It's rude.

Totally agree, panic in a library is a smell

Re: Go Style

#135

Post by vlunkr »

jawzz wrote: post #69
Xeoncross wrote: post #58

Earlier quoted context omitted.

The constancy in Go makes this better. I have come to expect `r` to be an io.Reader or http.Request depending on context. There are a few interfaces in Go that are used heavily and I don't mind that people often use a single character for them. It's the same thing as everyone using `i` for iterators.

This makes me wonder: what if there was a language where variable names are determined according to the type, with the option of overriding with a custom name. So a variable of type http.Request would automatically be named “req”, the next one in scope would be “req2”, etc. If you think about it, when you solve a physics problem, for instance, you call every mass “m1”, “m2”, etc. Maybe this would be another step in G…

What if I introduce a new http.Request between 1 and 2? Now all the references are broken.

Re: Go Style

#136

Post by kevmo314 »

bpicolo wrote: post #63
Xeoncross wrote: post #58

Earlier quoted context omitted.

The constancy in Go makes this better. I have come to expect `r` to be an io.Reader or http.Request depending on context. There are a few interfaces in Go that are used heavily and I don't mind that people often use a single character for them. It's the same thing as everyone using `i` for iterators.

I just use reader//req. Code is instantly easier to read for me personally and no time has been wasted. It's all preference, of course.

Sometimes you run into packages called reader which makes for a less fun time using variable names that are also words.

Re: Go Style

#137

Post by jrockway »

leetrout wrote: post #81

> Go interfaces generally belong in the package that consumes values of the interface type, not a package that implements the interface type. The implementing package should return concrete (usually pointer or struct) types. I like this rule. Most companies violate it everywhere. There are good times to ignore it but I always push for func NewThing To return something other than the interface type. The last Go interv…

Interfaces are the most misused feature of Go. I think people like to prototype their API by typing in all the functions they intend to implement, so the interface acts as a template for their program that they can fill out. This, unfortunately, is not what they're for.

I have a longer rant about this here: https://jrock.us/posts/go-interfaces/

Re: Go Style

#138

Post by kevmo314 »

CSSer wrote: post #76
mroche wrote: post #60

I found the following statement in the Maintainability section interesting: > Maintainable code minimizes its dependencies (both implicit and explicit). Depending on fewer packages means fewer lines of code that can affect behavior. Avoiding dependencies on internal or undocumented behavior makes code less likely to impose a maintenance burden when those behaviors change in the future. Obviously this guide was writte…

A lot of this comes down to available resources too. I used to hate how many third party things we used on principle and because I directly felt all the pain of tying them together. Now I’m a lead and I still dislike it but because I have a realistic read on how much bandwidth my team has I think this has balanced my view. I also still feel the pain but sometimes more indirectly (code reviews, for example). I think w…

This works with high quality or high familiarity libraries, which usually stem out of doing something very simple, but as I've gotten more experienced I've learned that most libraries it's faster and clearer to write the one or two functions I need myself instead.

Re: Go Style

#139

Post by akshayshah »

panabee wrote: post #126

has anyone compiled a comprehensive list of style guides from leading companies? google has published a style guide, but it doesn't seem like facebook and netflix do. it would be awesome to have one central list of best practices from leading tech companies. we started one on github, but it's woefully limited: https://github.com/HotpotDesign/Developer-Style-Guides could anyone kindly recommend better ones?

https://github.com/uber-go/guide/blob/master/style.md

Re: Go Style

#140

Post by jrockway »

masklinn wrote: post #113
robmccoll wrote: post #106

Earlier quoted context omitted.

Yep - return concrete types, but also make sure you have an assertion along the lines of: var _ IfaceType = &ConcreteType{} Somewhere, else you risk not knowing that a change to ConcreteType broke is implementation of IfaceType in a way that you might not know about until a rare runtime code path is executed.

> Somewhere, else you risk not knowing that a change to ConcreteType broke is implementation of IfaceType in a way that you might not know about until a rare runtime code path is executed. Why would runtime be involved? Surely if ConcreteType doesn't satisfy the interface anymore then the compiler will catch that at any site where a ConcreteType is being used as / cast to an IfaceType? Or are you talking about iface-…

The compiler will catch it at the point of use, but it's clearer if the error is at the point of declaration. Consider:

   type FooReader struct{}
   var _ io.Reader = FooReader{}

   func (r FooReader) Raed(p []byte) (int, error) { return 0, nil }
Before you even use FooReader as an io.Reader, you can find that you typo'd "Read". This is useful in practice because you probably wrote FooReader to have a bunch of other methods that aren't implementing io.Reader, and it's possible that your tests for this object don't actually ever use it as an io.Reader. So you won't notice this mistake until someone tries it elsewhere in the codebase.

It also acts as documentation that you intend for this thing to be an io.Reader. But I also recommend that you document Read as "// Read implements io.Reader." to be extra explicit.

Post reply on HN