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

81–90 of 212 posts

Re: Go Style

#81

Post by leetrout »

> 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 interview I was in I brought this up and the argument was that you cant test things if you are not returning the interface and I disagree entirely.

I love the power of duck typing with interfaces but give me concrete things that quack.

Re: Go Style

#82

Post by Thaxll »

throwaway2203 wrote: post #73
Thaxll wrote: post #72

Earlier quoted context omitted.

If you rely on naming function to know if things can be mutated you're doing things wrong. The only source of truth is the type received.

Why? Let's say I have a table full of cars and have a method > func Car(id string) Car How do I know whether it fetched that from the database or created a new one and returned that to me?

Only the type Car matters, why would the function name tells you anything about mutation? It does not tells you if you receive *Car or Car or if it's a Car but pointers inside.

Re: Go Style

#83

Post by notpushkin »

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…

https://en.wikipedia.org/wiki/Hungarian_notation

Re: Go Style

#84

Post by tragomaskhalos »

xiaq wrote: post #21
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 (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

Re: Go Style

#85

Post by mikepurvis »

philote wrote: post #41
thunky wrote: post #40

Earlier quoted context omitted.

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.

I agree. Plus, with IDEs and auto-completion, why not use longer names?

If you have to use that name a bunch of times close together, it bloats line lengths which also affects readability.

Re: Go Style

#86

Post by avianlyric »

everybodyknows wrote: post #79
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…

> A variable created at file scope How does one declare a variable to be of file scope in Go? An ordinary "var x int" has package scope, visible from any file in the directory (aside from the special cases around _test.go files). Scope of package import declarations is narrowed to a single .go file, but these of course are not variables .

I think you’re reading this too literally. They likely just mean file scope from a purely usage perspective. I.E. you only use the variable in one file, it doesn’t matter how the language processes it into a computational scope

Re: Go Style

#87

Post by Jiro »

speedyapoc wrote: post #55
wingerlang wrote: post #44

Earlier quoted context omitted.

Never having to figure out what a function actually does is nice. builder.makeThing("a", true, true, 46) [builder makeThingNamed:"a" isRound:YES isRed:YES size:46] or lately builder.makeThing(named: "a", isRound:true, isRed:true, size:46)

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".

Re: Go Style

#88

Post by charlieflowers »

still_grokking wrote: post #62
charlieflowers wrote: post #38

Earlier quoted context omitted.

You can make your own Maybe with generics.

And why isn't this build-in since the beginning like in any other sane language? A language where you need to constantly write wrappers around everything just to get basic functionality is quite a miserable language, imho. That's like C…

Completely agree.

Re: Go Style

#89

Post by notpushkin »

Thaxll wrote: post #82
throwaway2203 wrote: post #73

Earlier quoted context omitted.

Why? Let's say I have a table full of cars and have a method > func Car(id string) Car How do I know whether it fetched that from the database or created a new one and returned that to me?

Only the type Car matters, why would the function name tells you anything about mutation? It does not tells you if you receive *Car or Car or if it's a Car but pointers inside.

Because I want to know what function does?

Re: Go Style

#90

Post by everybodyknows »

avianlyric wrote: post #86
everybodyknows wrote: post #79

Earlier quoted context omitted.

> A variable created at file scope How does one declare a variable to be of file scope in Go? An ordinary "var x int" has package scope, visible from any file in the directory (aside from the special cases around _test.go files). Scope of package import declarations is narrowed to a single .go file, but these of course are not variables .

I think you’re reading this too literally. They likely just mean file scope from a purely usage perspective. I.E. you only use the variable in one file, it doesn’t matter how the language processes it into a computational scope

It absolutely does matter. If I'm editing the file in which the package-scope variable (or type, or const) is declared (and also referenced) and decide on the fly to subtly change its semantics, forgetting that the same is also referenced from some other file within the package, I have likely just created a bug. Worse, the bug will likely manifest itself only at run time.
Post reply on HN