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

101–110 of 212 posts

Re: Go Style

#101

Post by david422 »

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.

Or in languages that you can import a resource but give it a custom name. So whenever you are reading someone else's code you have to double check to understand what is going on. For instance, import DiskUtils as DU, and now all the code references DU.diskSpace()

Re: Go Style

#102

Post by jen20 »

metaltyphoon wrote: post #75
encryptluks2 wrote: post #24

Interesting that Google uses GitHub still. With Microsoft owning it and it becoming less free than alternatives, you'd think for documentation like this they'd use an externally hosted GitLab instance for their external projects or that they'd have acquired something to compete with GitHub by now like Gitea.

Less free? Microsoft didn't change a damn thing on GH, in fact its only getting better after acquisition.

Another case of the lack of distinction in English between "libre" and "gratis" causing problems, I see.

Re: Go Style

#103

Post by BrainVirus »

>Concise Go code has a high signal-to-noise ratio.

A few lines later:

  // Good:
  if err := doSomething(); err != nil {
      // ...
  }
"Tell me, how many lights you see?"

Re: Go Style

#104

Post by masklinn »

Jiro wrote: post #87
speedyapoc wrote: post #55

Earlier quoted context omitted.

Right? I have never understood the frustration around named parameters like this. It helps reduce cognitive load quite a bit.

It increases cognitive load when writing the function call, since you now need to remember what kind of true to use. It also increases cognitive load for people who either do already understand the parameters or who are doing something for which the parameters are not relevant; it's harder to ignore a long thing than to ignore a plain "true".

> It increases cognitive load when writing the function call, since you now need to remember what kind of true to use.

There is no "kind of true".

> It also increases cognitive load for people who either do already understand the parameters

By letting them see what the parameter they remember is? There's no cognitive load to seeing what you expect.

> or who are doing something for which the parameters are not relevant;

If the language doesn't have optional parameters, all parameters are relevant. By making parameters named, you avoid having to count positional parameters as in MS APIs to ensure you didn't get one in the wrong slot.

> it's harder to ignore a long thing than to ignore a plain "true".

Which is very much valuable. It's much easier to notice mistakes than when you've got 11 positional parameters of which 2/3rds are usually set to 0/null.

Re: Go Style

#105

Post by masklinn »

Zach_the_Lizard wrote: post #17
enneff wrote: post #15

Earlier quoted context omitted.

The question: what is the state of your server after a handler panics? The answer: you have no idea. It is not wise to continue serving requests when you may have serious issues in the state of your server. Maybe some central data structure is now corrupt. You have no way of knowing. Fail fast and fail hard. OTOH, maybe your priorities are different and you would prefer to be more available than correct. In that case…

In my experience, the panic is most likely because someone accessed a nil field when adapting some data. Nothing is corrupt, we just threw an exception in a mundane way. The reality is this is far more common than something truly fatal. Mistake for someone or not, it probably is correct for most use cases

> In my experience, the panic is most likely because someone accessed a nil field when adapting some data. Nothing is corrupt, we just threw an exception in a mundane way.

Even more so if a database is involved (which is generally the case), because odds are the transaction just gets rolled back and there's basically nothing that could be corrupted.

Re: Go Style

#106

Post by robmccoll »

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…

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.

Re: Go Style

#107

Post by Vendan »

knorker wrote: post #64
Zach_the_Lizard wrote: post #17

Earlier quoted context omitted.

In my experience, the panic is most likely because someone accessed a nil field when adapting some data. Nothing is corrupt, we just threw an exception in a mundane way. The reality is this is far more common than something truly fatal. Mistake for someone or not, it probably is correct for most use cases

You're assuming that the code was written exception safely. E.g. mu.Lock() foo := bar[baz] // Go is sold as a language without exceptions, so people don't write exception-safe code. Which is fine, except when exceptions are actually caught.

That wouldn't pass a code review where I work... Use a defer to do the unlock

Re: Go Style

#108

Post by euroderf »

icedchai wrote: post #51
watt wrote: post #25

Earlier quoted context omitted.

Indeed, this is one Go convention that I strongly dislike. Java did have that approach once (HTMLDOMURIReference, XMLIDREF and the likes) but they learned their lesson. And what's the basis of capitalizing D in ID?

It is commonly abbreviated that way in normal life (see https://en.wikipedia.org/wiki/Identity_document ) When I see "Id" in code, I wince.

Rage. Raging Id.

Re: Go Style

#109

Post by masklinn »

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…

That rule is not without its issues when pointers get involved, due to the typed nil problem.

Re: Go Style

#110

Post by gilgad13 »

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…

I imagine that opinions such as this have influenced this recommendation: https://research.swtch.com/deps . I think there is some spirit in Go of not taking on a ton of small dependencies, but that may be a hold-over from before Go had a built-in package manager.

I think as an organization grows to some combination of available resources and severity of an outage this view becomes more and more common.

Post reply on HN