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

41–50 of 212 posts

Re: Go Style

#41

Post by philote »

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.

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

Re: Go Style

#42

Post by gopher_1234 »

The kubernetes ecosystem has a lot of go code which consequentially suffer from nil panics. Thankfully they recover otherwise we'd see an absolute shit ton of pod restarts.

In general, please stop panicking in library Go and Rust code. It's rude.

Re: Go Style

#44

Post by wingerlang »

raverbashing wrote: post #30
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

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)

Re: Go Style

#45

Post by sidlls »

> 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 from Enterprise Java style identifiers. That is, TheyAreGenerallyTooLongAndIHateThemAll.

Re: Go Style

#46

Post by nebiros »

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…

No post body was provided.

Re: Go Style

#47

Post by hoosieree »

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…

The more I think about this rule the more I like it.

One thing I would add is if you're writing a library, think of the people using it. Are they going to curse you every time they have to write YourModule.ExtremelyVerboseMethodNameWhyOhWhyIsItSoLong, even if it only appears once in your module?

As soon as you start sharing code, you can't know how many times a name will appear. So err on the side of brevity, for our sakes.

Re: Go Style

#48

Post by oracardo »

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.

  [1] https://google.github.io/styleguide/go/decisions#assertion-libraries
  [2] https://google.github.io/styleguide/go/best-practices#leave-testing-to-the-test-function
  [3] https://google.github.io/styleguide/go/decisions#initialisms
  [4] https://google.github.io/styleguide/go/decisions#function-formatting

Re: Go Style

#49

Post by vbezhenar »

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?

One reason so use short names is to keep lines short and reduce line wrapping. This helps to read code, especially when you do 3-way merges.

Re: Go Style

#50

Post by whalesalad »

Cthulhu_ wrote: post #37
is_taken wrote: post #23

Earlier quoted context omitted.

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 }

This is the answer. Write a utility instead of get frustrated with the language; be pragmatic. Same with looking for libraries that do something trivial.

I’m used to parsing a date time with things like %Y-%m-%d not the asinine way Go does it.
Post reply on HN