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

171–180 of 212 posts

Re: Go Style

#171

Post by jawzz »

notpushkin wrote: post #83
jawzz wrote: post #69

Earlier quoted context omitted.

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

Oh cool, thanks for that.

Re: Go Style

#173

Post by dpifke »

gouggoug wrote: post #158
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…

Slightly unrelated to Parent: I struggle very hard creating my own interfaces for my own programs. I haven't found any literature online teaching the _right way_ of coming up with your interface. For example, I very often struggle with function parameters and return types: should my interface functions only take basic type and return basic types? Can my interface function take more concrete types? Should my interface…

Looking up *object.Commit from SHA string doesn't seem like something you want to make every Checker implementation do (even if it's mostly boilerplate), so passing a higher-level object makes sense here.

What you might want to do is also define an interface for what Git calls "commit-ish"[0] objects, and use that in place of *object.Commit. Then you could pass e.g. *object.Tag in place of *object.Commit.

Think of the interface as a contract between implementations and users of the data structure. Typically, you use an interface when multiple implementations are capable of fulfilling the same contract. If there's only one implementation, you likely don't need an interface—for instance, you can ignore my suggestion about abstracting commit-ish if you're pretty sure your checker would never be called for a tag.

Interfaces are often useful when testing, because a mock implementation can fulfill that same contract. For instance, you might implement a *object.MockCommit which just uses static values instead of actually operating on a Git repository, and then pass that for your commit-ish in unit tests for various Checkers.

[0] https://git-scm.com/docs/gitglossary#Documentation/gitglossa...

Re: Go Style

#174

Post by shepherdjerred »

jrockway wrote: post #159
shepherdjerred wrote: post #155

Earlier quoted context omitted.

I don't believe so. Imagine you're new to Go and you haven't mentally mapped all of these abbreviations. What would you rather read, `r` or `reader`?

Designing an API that "stutters" is a very common mistake that many programmers make. reader.Read() is pretty jarring. There is also nothing wrong with naming variables after what they're for instead of what they are. Consider io.Copy(dst, src). That's nicer than io.Copy(reader1, reader2).

Sure, so call your reader `file` or `network` or `stream`. Don't call it `r`. Nobody is charging you by the character.

It isn't a huge deal when the code is simple, e.g. you create a reader named `r` and in the next line you use it. That's easy to understand. The problem is that the pattern propagates. A few more lines of code are added, the reader is still named `r`. It's name `r` here, so we start putting it in a struct as `r`. Soon enough the codebase is littered with instances of `r`. Not great.

Re: Go Style

#175

Post by marcus_holmes »

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…

ok, fair point, bad example. But having to declare a constant for the number of percentage points in a unit is insane and needs to stop. Bad linter, bad.

Re: Go Style

#176

Post by SEJeff »

ehsankia wrote: post #133
SEJeff wrote: post #128

Earlier quoted context omitted.

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.

I meant i as in the iterator variable for a counter like when using enumerate() or a c style for loop where you manually specify the list index.

Re: Go Style

#177

Post by mprime1 »

jrockway wrote: post #137
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/

Thank you for sharing this.

I was struggling with this just today: Realizing I keep putting off writing tests for some modules because mocking a certain mega interface is a pain.

Your post gives me some great hints for things to try. Looking forward to experimenting with it.

Re: Go Style

#178

Post by Too »

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…

Terraform has an extreme approach to that, every time you reference a variable you have to spell out the complete TYPE.NAME.ATTRIBUTE, eg resource.aws_s3_bucket.my_bucket.website_endpoint. There is no way to access my_bucket without the whole prefix, even after assigning it to local variable you must prefix the reads as locals.my_bucket.

For sensitive infrastructure this makes sense, i surely wouldn't want to write other code like this.

Re: Go Style

#179

Post by Too »

knorker wrote: post #169
Vendan wrote: post #107

Earlier quoted context omitted.

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

I would also not allow it. I'm saying the problem is that core Go developers say "Go doesn't have exceptions", which is manifestly false, but causes people to not write exception safe code. But despite you and me, I'm saying there's a lot of broken code out there because of this doesn't-but-actually-does misinformation. And it's very annoying that you have to tell people to do: var i int func() { mu.Lock() defer mu.U…

This is like the biggest thing scaring me away from Go. This half-assed "we don't use exceptions, so you shouldn't have to care about it, except when we do, so you still must write proper defers, which are now doubly verbose because nobody considered it a primary use case"... In any other language, a mutex outside a using/with/try-with/RAII would be instantly flagged in code-review or linter tools. In many cases even hard to write incorrectly, due to entering context being only way to acquire the lock.

Now this middle ground leaves you having to write triple verbose if err != null on every third line of your code and still not be safe from panics-that-shouldnt-have-been-panics.

As parent says, the only way panics can ever work is if the top-level never catches and recovers from them. I'm no expert in go but that would mean in such perfect world, defer should hardly ever be needed at all, not even for locks? Only for truly external resources? But now with popular web servers doing such recovery, the entire ecosystem got polluted and all need to handle it?

Re: Go Style

#180

Post by Ferret7446 »

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…

That could be easily done by the editor in a statically typed language like Go, so there is no point bloating the language with it. Just turn on an overlay that displays the types of all names. I believe LSP adds this to many languages/editors already.
Post reply on HN