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

61–70 of 237 posts

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

#61

Post by entity345 »

croshan wrote: post #59
entity345 wrote: post #50

Earlier quoted context omitted.

Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

It's really more of a language community issue, but communities of a language are commonly referred to by the name of the language itself.

I'm sure there are many actual professionals using Go. Not just script kiddies.

I happen to be learning Go coming from a C background. I find "The Go Programming Language" by Donovan and Kernighan exemplary and the decades of experience that went into the language really show.

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

#62

Post by dilap »

pcwalton wrote: post #48
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?

Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete. Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.

I feel like I have the opposite problem.

If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols.

So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.

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

#63

Post by nkozyra »

futureastronaut wrote: post #52
entity345 wrote: post #50

Earlier quoted context omitted.

Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

Dogmatism and Go are peas in a pod. If your variable is longer than one character you're a dirty Java programmer, or something to that effect.

The article says basically the opposite.

Local, short-lived variables are short, this is nothing new. See: the ephemeral loop variable i.

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

#64

Post by aczerepinski »

entity345 wrote: post #50
argd678 wrote: post #46

> 2.1. Choose identifiers for clarity, not brevity This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you’re not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn’t read the code.

Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

I disagree with this because I personally change my coding style based on the language I’m writing. When I write Go I do use one letter variable names like u := User because I’m modeling what I see from some of the top Go developers (core team members, etc). When I write JS I usually follow the popular airbnb style guide and order my code differently than I would in any other language. When I write ruby I look for naming conventions that read like English. I’m always trying to write idiomatic code that will feel familiar to readers who write that language.

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

#66

Post by Scramblejams »

networkimprov wrote: post #47
ragona wrote: post #42

Earlier quoted context omitted.

> A long function is easier to understand than an exploded one. This is a pretty controversial position, and quite situational in my opinion. I absolutely agree that having to hop all over the source to understand something is frustrating, but that doesn't mean that very long functions are the right solution. Some combination of reasonably named helper methods and a function flow that makes the logic easy to parse sh…

I took issue with this because it's a conventional wisdom, and does a fair bit of damage. Single-caller functions attract other callers over time, gain backwards-incompatible features, and result in regressions.

This is one reason I like nested functions. They’re not available to the surrounding scope so they don’t succumb to these weaknesses, while also allowing you to organize your very long function internally by task. I use ‘em in Python all the time.

It’s a bummer that more languages don’t support them, though you can get there with lambdas too, sometimes at the cost of more syntax.

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

#67

Post by jpttsn »

twentythree wrote: post #65

> 2.3. Don’t name your variables for their types What's the best way to handle a situation where you use two different types for the same data? e.g. var usersMap map[string]*User var usersList []*User

I’d call the former usersByID (if that’s what the string is)

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

#68

Post by samstokes »

twentythree wrote: post #65

> 2.3. Don’t name your variables for their types What's the best way to handle a situation where you use two different types for the same data? e.g. var usersMap map[string]*User var usersList []*User

How about describing the intended use of the collections? E.g.

    var usersByUsername map[string]*User
    var usersToEmail []*User

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

#69

Post by xyzzy_plugh »

mrbrowning wrote: post #54
TheJazi13 wrote: post #7

Earlier quoted context omitted.

I’d argue there’s a failure of the code to some extent to need such extsenibility with documentation. I’ve often found when I need more info outside of Godocs that simply clicking through and diving into the source provided me with all the answers I needed to know.

This attitude, which I'll paraphrase as "needing any feature that I personally consider unnecessary is a code smell," is endemic to the Go community and a big reason why I still find myself frustrated by it on a daily basis even after a month of using it for a greenfield project. I don't like the language itself, since I'm generally in favor of a language offering more affordances rather than fewer, but it's fine to…

I couldn't disagree more. I think it comes down to personal preferences, mostly.

I get so much more done in Go, have fewer maintenance issues, and more frequently collaborate with other folks/contribute to other projects.

> I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered.

I could -- and do -- say the same about the Java ecosystem.

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

#70

Post by networkimprov »

Scramblejams wrote: post #66
networkimprov wrote: post #47

Earlier quoted context omitted.

I took issue with this because it's a conventional wisdom, and does a fair bit of damage. Single-caller functions attract other callers over time, gain backwards-incompatible features, and result in regressions.

This is one reason I like nested functions. They’re not available to the surrounding scope so they don’t succumb to these weaknesses, while also allowing you to organize your very long function internally by task. I use ‘em in Python all the time. It’s a bummer that more languages don’t support them, though you can get there with lambdas too, sometimes at the cost of more syntax.

Go has closure functions; great feature.

One of the (few) things I like about Javascript is the ability to define a closure anywhere in the containing function, so it appears in the order of operations:

  function f() {
    setTimeout(fDing, 2000);
    g();
    function fDing() {
      ...
    }
  }
Post reply on HN