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

201–210 of 212 posts

Re: Go Style

#201

Post by randomswede »

tragomaskhalos wrote: post #84
xiaq wrote: post #21

Earlier quoted context omitted.

> 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 (us…

Yeah maybe. I've worked on code where there were constants defined for minutes-in-hour, hours-in-day etc though, and that was just annoying; it's conceivable that our culture will one day decide that the Babylonians were idiots and we should use the French revolutionary clock instead, but I'll take my chances

How many seconds in an hour? Most of the time, 3600, occasionally 3601, and very rarely 3599. Hours in a day? Mostly 24, but 23 once a year ad 25 once a year.

These all seem like good reasons to make then functions (taking a timestamp as a n argument) rather than mostly-correct constants.

I swear, the more I learn about calendars and timekeeping, the more I realise I never ever want to deal with it.

Re: Go Style

#202

Post by gbalduzzi »

gogogogogogo wrote: post #154
gbalduzzi wrote: post #94

Earlier quoted context omitted.

I agree that most types come with a natural variable name. However, in many cases a more descriptive name is way appropriate. On top of my mind: - Multiple variables of the same type. How are you supposed to distinguish between req and req2? Compare it to something like "apiReq" and "cdnReq" - Primitive types, that does not inherently carry a domain value. An integer called "seconds" or "max_offset" has a lot more me…

The real question from this example is: why are you creating two http requests in the same scope before using them? I've been writing Go cloud stuff for the better part of a decade and "req" for a request has never been ambiguous because I go ahead and send the request and process the response before sending another one, at which point I can just reassign the variable and let the first one fall out of scope.

The request type is just an example, of course, building up from the example in the comment I was replying to.

Re: Go Style

#203

Post by robertlagrant »

jawzz wrote: post #170
gbalduzzi wrote: post #94

Earlier quoted context omitted.

I agree that most types come with a natural variable name. However, in many cases a more descriptive name is way appropriate. On top of my mind: - Multiple variables of the same type. How are you supposed to distinguish between req and req2? Compare it to something like "apiReq" and "cdnReq" - Primitive types, that does not inherently carry a domain value. An integer called "seconds" or "max_offset" has a lot more me…

You’re right. Going back to my physics example, all the variables in a physics problem are actually of the same type, float. So you’d need more specific types, but that would be infeasible-the whole point of types in a general purpose language is that they’re general enough for any use case. If you were just coding physics problems you could have types restricted to the physics domain, that is, physical units. Which…

> Going back to my physics example, all the variables in a physics problem are actually of the same type, float

This is why some people recommend a practice I've forgotten the name of, where they defined a new type that maps to language type. So type Mass could just be a float, but you know better how to treat it.

Re: Go Style

#204

Post by robertlagrant »

michaelcampbell wrote: post #192
Ferret7446 wrote: post #185

Earlier quoted context omitted.

What's wrong with this? The code is doing... exactly what it says. Call doSomething and if it returns an error do something else. What part of that is noise?

As does most code. That doesn't mean it has a high signal:noise ratio.

Some of these threads seem like that party game where people write a story together, but each player can only read the previous sentence of the story when writing the next one.

Re: Go Style

#205

Post by robertlagrant »

Zamicol wrote: post #95
throwaway2203 wrote: post #71

Go is absurd. It's opinionated in all the wrong ways. > Functions that return something are given noun-like names. > // Good: > func (c Config) JobName(key string) (value string, ok bool) > A corollary of this is that function and method names should avoid the prefix Get. > // Bad: > func (c Config) GetJobName(key string) (value string, ok bool) That's dumb. I'd like a function to be GetJobName to indicate that it do…

I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature. That advice is a consequence of Go expecting function signatures to be read and understood. That's not the right choice for all programming languages, but for Go it works.

> I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature.

But I thought Golang doesn't have function overloading, so you also have to name the function appropriately for its use?

Re: Go Style

#206

Post by stevemethiew »

jrockway wrote: post #160
twblalock wrote: post #150

Earlier quoted context omitted.

Hiding errors like that is going to make it hard to figure out what is going on as more and more wrappers like this pile up. If time.Parse is failing, you either have bad input or a bug, right? If you are ok with this failing without even logging the error, something might be wrong with the design.

Hiding errors saves less than a second of typing, at the cost of making every five minute bugfix a one day bugfix. Don't do it. You can't build your own programming language inside of Go. If you absolutely cannot mentally handle functions returning an error and you having to type "if err != nil { fix the problem }", you really need to find a different programming language. But, errors happen all the time, and handlin…

No post body was provided.

Re: Go Style

#207

Post by throwaway2203 »

robertlagrant wrote: post #205
Zamicol wrote: post #95

Earlier quoted context omitted.

I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature. That advice is a consequence of Go expecting function signatures to be read and understood. That's not the right choice for all programming languages, but for Go it works.

> I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature. But I thought Golang doesn't have function overloading, so you also have to name the function appropriately for its use?

Yupppp. But you can't let function names get too long or everyone will laugh at you for being a Java dev writing Go.

Like I said, absurd.

Re: Go Style

#208

Post by euroderf »

randomswede wrote: post #201
tragomaskhalos wrote: post #84

Earlier quoted context omitted.

Yeah maybe. I've worked on code where there were constants defined for minutes-in-hour, hours-in-day etc though, and that was just annoying; it's conceivable that our culture will one day decide that the Babylonians were idiots and we should use the French revolutionary clock instead, but I'll take my chances

How many seconds in an hour? Most of the time, 3600, occasionally 3601, and very rarely 3599. Hours in a day? Mostly 24, but 23 once a year ad 25 once a year. These all seem like good reasons to make then functions (taking a timestamp as a n argument) rather than mostly-correct constants. I swear, the more I learn about calendars and timekeeping, the more I realise I never ever want to deal with it.

Tell the reader that this here code is prepared for leap years, leap seconds, leap hours:

  SecondsPerStandardHour = 3600 // or NormalHour or TypicalHour 
  HoursPerStandardDay = 24      // or NormalDay, TypicalDay

Re: Go Style

#209

Post by euroderf »

thomascgalvin wrote: post #65
sidlls wrote: post #45

> A little copying is better than a little dependency. Go takes this to an extreme, though. Generics helps, but the implementation is so limiting that it doesn't help much. > 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. Some (most) of the go code I've seen where I work suffers…

This is probably because Go doesn't allow function overriding. You can't have `streamFromUrl(foo)` and `streamFromUrl(foo, bar)`, so you end up with `streamFromUrlWithFoo(foo)` and streamFromUrlWithFooAndBar(foo, bar)`.

Right. It's kosher to have one simple "New(..)" function per package, for the key type in the package, but all the other constructors shall have verbose names.

Re: Go Style

#210

Post by euroderf »

oracardo wrote: post #48

In my opinion the hardest style rules to accept when trying to use this guide are: 1. Do not create "assertion libraries" like `assertEqual(x, y)` [1] 2. Leave testing to the Test function [2] 3. Intialisms (HTTPURL, IOS, gRPC) [3] 4. Function formatting [4] For the record I'm not saying I disagree with these. I just think that folks coming from other languages have a lot of built in muscle memory to do it other ways…

[3] is an Americanism, innit ? They'd rather write EBCDICBlah than EbcdicBlah. And in the same vein, W.H.O. instead of WHO, and 8:30 p.m. instead of 830pm.
Post reply on HN