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

21–30 of 212 posts

Re: Go Style

#21

Post by xiaq »

marcus_holmes wrote: post #10

> Name constants based on their role, not their values. If a constant does not have a role apart from its value, then it is unnecessary to define it as a constant. This breaks the linter in most cases because "magic numbers". Like having to declare a constant for the number of cents in a euro/dollar. I think Google are right in this case, and linters need to be smarter.

> Like having to declare a constant for the number of cents in a euro/dollar.

I agree with your point, but this is a bad example. Naming these constant CentsInEuro and CentsInUSDollar is consistent with the style guide.

As silly these examples are in isolation (of course a cent is 1/100 of a euro or a dollar), if you are writing code that processes currencies beyond euro and dollars, you will quickly end up with (using Chinese Yuan as an example):

    const (
        JiaoInCNYuan = 10
        FenInCNYuan = 100
        ...
    )
At which point adding

    const (
        CentsInUSDollar = 100
        CentsInEuro = 100
        ...
    )
is not just reasonable but a good idea.

Additionally, suppose your code needs to deal with historical currencies, you'll most likely need:

    const (
        ShillingsInOldBritishPound = 20
        PenceInOldBritishShilling = 12
        ...
    )
This is also a good example that the knowledge that a cent is 1/100 of a dollar or euro is highly culture-dependent. A British programmer from as late as 1970 will tell you that it's silly to create constants for these: of course there are 20 shillings in a pound and 12 pence in a shilling, everyone knows that! (I also like to think that they'd assume that a "cent" is 100 dollars because that's what centum means in Latin, but it's probably highly unlikely for them to never know US dollars and cents.)

Re: Go Style

#22

Post by Thaxll »

cytzol wrote: post #8

I found this "best practice" curious to read: > The standard net/http server violates this advice and recovers panics from request handlers. Consensus among experienced Go engineers is that this was a historical mistake. If you sample server logs from application servers in other languages, it is common to find large stacktraces that are left unhandled. Avoid this pitfall in your servers. I don't think I've ever seen…

How I understand it is that it's up to the user to create a panic handler middleware, which is perfectly valid and what most people are doing anyway.

Something like: https://github.com/go-chi/chi/blob/master/middleware/recover...

Re: Go Style

#23

Post by is_taken »

whalesalad wrote: post #20

golang driving me nuts these days. enjoying the performance, but time.Parse put me into a ragequit mode last night and I really wish it was possible to return a thing OR nil

Why not writing a small wrapper around time.Parse?

  func ParsedTimeOrNil(s string) *time.Time { 
   t1, err := time.Parse(time.RFC3339, s)
   if err != nil {
    return nil
   }
   return &t1  
  }

Re: Go Style

#24

Post by encryptluks2 »

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.

Re: Go Style

#25

Post by watt »

frou_dh wrote: post #18

Kinda amusing how the following section is complicated by the language's casing-based visibility feature https://google.github.io/styleguide/go/decisions#initialisms

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?

Re: Go Style

#26

Post by throw827474737 »

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

Yes, why they made that decision back then. However in the end the lib cannot and shouldn't know, and this decision needs to be intentionally done by the middleware. Correct for most use cases is not good enough here, should be always correct for such fundamental thing.

Re: Go Style

#27

Post by adamgordonbell » 

    > The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope. 

    > A variable created at file scope may require multiple words, whereas a variable scoped to a single inner block may be a single word or even just a character or two, to keep the code clear and avoid extraneous information.
I love how it covers both short iterators and long descriptive names under a single principle.

Re: Go Style

#28

Post by otabdeveloper4 »

cytzol wrote: post #8

I found this "best practice" curious to read: > The standard net/http server violates this advice and recovers panics from request handlers. Consensus among experienced Go engineers is that this was a historical mistake. If you sample server logs from application servers in other languages, it is common to find large stacktraces that are left unhandled. Avoid this pitfall in your servers. I don't think I've ever seen…

Presumably you have a load balancer in front of your Go code that's written using saner languages and assumptions that does handle errors correctly.

Re: Go Style

#29

Post by throw827474737 »

xienze wrote: post #14
evercast wrote: post #13

Earlier quoted context omitted.

I believe the idea is that 'panic' is considered something fatal. If it happens, the application should die unless you have a strong reason for it not to. If you can recover e.g. by returning HTTP 500 for a single request, it should be handled by returning errors up throughout the call stack, i.e., by error handling instead of panicking. It's definitely an opinionated approach though.

> I believe the idea is that 'panic' is considered something fatal. I think opinions in 3rd party Go code on what “fatal” means vary, that’s the issue. Sure it was intended to mean “this error is so bad the entire program needs to die right now” but in practice there’s cases where it’s treated more like an unchecked exception in Java, i.e., “I can’t recover from this so _I’m_ going to give up but _you_ can keep going…

> It can be argued whether or not that’s the right thing to do

No, because both approaches could be right at a higher level, to pretake that decision at this level is definitely wrong here?!

Re: Go Style

#30

Post by raverbashing »

adamgordonbell wrote: post #27

> The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope. > A variable created at file scope may require multiple words, whereas a variable scoped to a single inner block may be a single word or even just a character or two, to keep the code clear and avoid extraneous information. I love…

Good

Apple APIs are infamous for their long names. Not sure what they gain by it

Post reply on HN