Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Go: Real-world advice for writing maintainable Go programs

dave.cheney.net

Post reply on HN
Print view View original

191–200 of 237 posts

Re: Practical Go: Real-world advice for writing maintainable Go programs

#191

Post by sacado2 »

entity345 wrote: post #178
freyir wrote: post #177

Earlier quoted context omitted.

If you’ve seen any amount of Go and Java code (starting with, say, the standard libraries), you’d know these communities take very different approaches to variable names.

The point is that you do not choose the way to name variables based on a sheepish "it's the way the community does it". You're responsible for your own code, and your organisation's code. It has nothing to do with the language.

But then you end up with a non idiomatic coding style, which may be an issue if your code is open-sourced. I'd be very wary of a Java program where variable names are snake_cased, for instance: did they do it for a good reason? Are they just beginning java developers? Will I run into other ad hoc coding practice when trying to understand/maintain/extend their code?

Re: Practical Go: Real-world advice for writing maintainable Go programs

#192

Post by entity345 »

sacado2 wrote: post #191
entity345 wrote: post #178

Earlier quoted context omitted.

The point is that you do not choose the way to name variables based on a sheepish "it's the way the community does it". You're responsible for your own code, and your organisation's code. It has nothing to do with the language.

But then you end up with a non idiomatic coding style, which may be an issue if your code is open-sourced. I'd be very wary of a Java program where variable names are snake_cased, for instance: did they do it for a good reason? Are they just beginning java developers? Will I run into other ad hoc coding practice when trying to understand/maintain/extend their code?

Again, there is nothing "idiomatic" is poor naming, nor do I see what open source has to do with it...

Re: Practical Go: Real-world advice for writing maintainable Go programs

#193

Post by sacado2 »

entity345 wrote: post #192
sacado2 wrote: post #191

Earlier quoted context omitted.

But then you end up with a non idiomatic coding style, which may be an issue if your code is open-sourced. I'd be very wary of a Java program where variable names are snake_cased, for instance: did they do it for a good reason? Are they just beginning java developers? Will I run into other ad hoc coding practice when trying to understand/maintain/extend their code?

Again, there is nothing "idiomatic" is poor naming, nor do I see what open source has to do with it...

"Poor naming" is subjective. What is the correct name for a variable that associates a user's name with its configuration profile? userNameToConfigurationProfile? user_name_to_configuration_profile? userToConfig? profiles? userCfg?

If there was one true way to do it, everybody would adopt it (unless you consider some communities are just plain dumb).

Re: Practical Go: Real-world advice for writing maintainable Go programs

#194

Post by Casperin »

sacado2 wrote: post #187
briatx wrote: post #35

> Naming the Config parameter config is redundant. We know its a Config, it says so right there. > In this case consider conf or maybe c will do if the lifetime of the variable is short enough. This seems petty. Is it really that problematic to type out a few extra characters?

It is problematic for readability reasons as long as you are making complex expressions: configuration := NewConfiguration() configuration[word] = parameters[values[line][column]] - parameters[values[column][line]] vs conf := NewConfig() conf[w] = params[vals[i][j]] - params[vals[j][i]] It takes your brain more time to parse the first line. Now, there is an obvious limit, this is probably too much c[w] = p[v[i][j]] -…

The first version was too long to fit on the screen for me. Reading the second I missed the swapping of `i` and `j` -- only noticing it when I went back to the first version to figure out which parts of line I would assign to something if I were to rewrite the code.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#195

Post by fastbmk »

> Coming from Java? If you’re coming from a Java background, consider this rule of thumb. - A Java package is equivalent to a single .go source file.

Put a volume of a java package in one .go source file? Do all Go programming language advocates/evangelists have a mediocre intellectual level or just Dave Cheney?

Re: Practical Go: Real-world advice for writing maintainable Go programs

#196

Post by yiyus »

atombender wrote: post #133
diegs wrote: post #71

About half-way through and I think this is a great article, in particular the quotes and I also agree that the first 4 sections are generally applicable. One thing I disagree with is the remark about having fewer, big packages. Though conceptually I agree that avoiding having too many public APIs that aren't widely used makes sense, in practice --at least on the types of projects I tend to work on--I find that direct…

I often find myself wishing Go either allowed import cycles between packages, or allowed namespaces within a package. Because they can become unwieldy. For example, a common convention is to avoid redundancy. Let's say you have a package "builder". Your encouraged to have "builder.New()" as a constructor, not "builder.NewBuilder()". Fine. Now let's say you need two types of builders: One for building "schemas", one f…

Could you work around this somehow using a combination of internal packages and type aliases in public packages?

Re: Practical Go: Real-world advice for writing maintainable Go programs

#198

Post by entity345 »

sacado2 wrote: post #193
entity345 wrote: post #192

Earlier quoted context omitted.

Again, there is nothing "idiomatic" is poor naming, nor do I see what open source has to do with it...

"Poor naming" is subjective. What is the correct name for a variable that associates a user's name with its configuration profile? userNameToConfigurationProfile? user_name_to_configuration_profile? userToConfig? profiles? userCfg? If there was one true way to do it, everybody would adopt it (unless you consider some communities are just plain dumb).

We're discussing 'good naming' as defined in the article and first comment of this comments thread:

> 2.1. Choose identifiers for clarity, not brevity

Cosmetic considerations like snake or camel case are irrelevant.

The advice above is standard good practice that is not dependent on the language used.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#199

Post by dagw »

sacado2 wrote: post #187
briatx wrote: post #35

> Naming the Config parameter config is redundant. We know its a Config, it says so right there. > In this case consider conf or maybe c will do if the lifetime of the variable is short enough. This seems petty. Is it really that problematic to type out a few extra characters?

It is problematic for readability reasons as long as you are making complex expressions: configuration := NewConfiguration() configuration[word] = parameters[values[line][column]] - parameters[values[column][line]] vs conf := NewConfig() conf[w] = params[vals[i][j]] - params[vals[j][i]] It takes your brain more time to parse the first line. Now, there is an obvious limit, this is probably too much c[w] = p[v[i][j]] -…

In your example I would compromise with:

    conf[w] = params[vals[line][column]] - params[vals[column][line]]
or even:

    conf[w] = params[vals[l][c]] - params[vals[c][l]]
if you really want to save a couple of characters. Confusing which loop index is indexing which dimension is far too easy.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#200

Post by fastbmk »

ilovecaching wrote: post #136

So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can c…

No wonder most Go developers come from Python, not C++. Go is a faster Python with concurrency. Go is not suitable for serious projects, but is ok for mediocre devops stuff.
Post reply on HN