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

51–60 of 212 posts

Re: Go Style

#51

Post by icedchai »

watt wrote: post #25
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?

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.

Re: Go Style

#52

Post by vbezhenar »

fn1 wrote: post #16
xienze wrote: post #14

Earlier quoted context omitted.

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

> 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.” Java has a supertype for unrecoverable problems like out-of-memory-errors. It's called "Error", a subtype from Throwable. Exceptions are also Throwables, but they are NOT errors.

There's nothing unrecoverable about Error exceptions. If one thread hit a bug and threw StackOverflowError, it's not a reason to kill the entire application or even thread itself, just unwind stack, show some error and continue processing next task. The only tricky situation I'm aware of is OutOfMemoryError, because it can affect other threads. I'd prefer to restart the server. But again it's just because typical code allocated heap all the time. One can write code carefully without heap allocations and this code will work just fine with OOM errors thrown around.

Re: Go Style

#53

Post by liampulles »

bushbaba wrote: post #2

Isn’t the point of go is that go fmt follows the languages global style guide?

Yes - I always thought that Go took an opinionated position that the style is whatever gofmt outputs. This is a very limited set of style "rules" - that is on purpose. gofmt is meant to allow one to spend near zero time manually styling code or picking people up on styling in reviews.

Re: Go Style

#54

Post by benji-york »

Joker_vD wrote: post #31
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?

Because "ID" is short for "Identification Datum".

citation needed

Re: Go Style

#55

Post by speedyapoc »

wingerlang wrote: post #44
raverbashing wrote: post #30

Earlier quoted context omitted.

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

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.

Re: Go Style

#56

Post by benji-york »

watt wrote: post #25
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?

I also dislike "ID" vs "id" (as short for "identity"), but there is some case for it. The below are from Webster's Third New International Dictionary Unabridged.

First, the case for "id":

    id abbreviation  
    1 [Latin idem] the same
Now for "ID"

    ID noun, plural ID's or IDs [REVISED] [identification]
    1 a : documentation bearing identifying information

Re: Go Style

#57

Post by madeofpalk »

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.

There's also a bit of Fitt's Law in here as well - I find it a lot harder to select, or put my cursor in, a single letter variable. So if I want to rename `i` to something else, I must carefully select `i`, whereas with a longer variable I find it easier to put my cursor in the middle of `index` and hit F2.

Re: Go Style

#58

Post by Xeoncross »

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.

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.

Re: Go Style

#59

Post by ErikCorry »

madeofpalk wrote: post #57
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.

There's also a bit of Fitt's Law in here as well - I find it a lot harder to select, or put my cursor in, a single letter variable. So if I want to rename `i` to something else, I must carefully select `i`, whereas with a longer variable I find it easier to put my cursor in the middle of `index` and hit F2.

If you are using a mouse for things like this you already lost though.

Re: Go Style

#60

Post by mroche »

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 written for internal Google use, but it's interesting to see a recommendation that appears to run a bit counter to how ecosystems tend develop for languages that have easily consumable packaging solutions. It's not uncommon to look at a Go, Rust, Node, Python, etc project and see many dependencies (direct and indirect) in use, most of which you have no idea what they're being used for outside of some of the most popular packages. Not that I think the suggestion is wrong, I fully support fewer dependencies and using external packages where they make sense. I start to get uneasy when you see a tree of dependencies of unknown code, but I don't have the time myself to read through all of those packages.

Post reply on HN