Live data from Hacker News

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

dave.cheney.net

31–40 of 237 posts

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

#31
This is so fortuitous as I started writing my first real Golang service and as a python dev I have no idea what I am doing.

But one refreshing thing is how opinionated the language and the frameworks are refreshing as there’s only one acceptable way to do many things.

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

#32
post #29

Earlier quoted context omitted.

I guess it's hard to get around to the advanced features when so few people even bother to take advantage of the basic ones. Documentation for most Go libraries I've come across has been pathetic compared to similar things in Python or PHP. edit: Compare to something like Racket: https://docs.racket-lang.org/plot/intro.html?q=graph#%28part...

Disagree hard on Go vs Python. Python is my day job, but documentation is rough . You're likely not going to get documentation for all the types, and if you do it's usually in one giant page and you can't tell which class's `__str__()` docstring you're looking at. Often you'll have a method with some terse description for parameters that don't completely describe the types accepted for a parameter. Most of this stuff…

I'm mostly comparing this:

http://flask.pocoo.org/docs/1.0/api/#api

to this:

https://golang.org/pkg/net/http/

If the source weren't hyperlinked, I'd be lost on the latter.

edit: I love Racket's documentation. I've been using it for so many in-house things because I can just read what the function does in English--instead of having to run experiments or dig through someone else's code.

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

#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?

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

#36
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?

The issue w/ calling it "config" is that you end up with the confusing scenario where "config" is the object and "Config" is the type, differing only in casing.

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

#37
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?

The argument is that it is not fundamentally better to use the longer name in the given context, so why make it longer? I'd say it isn't about how long the variable takes to type either, but how long the code takes to read and parse.

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

#38
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?

And this is worse advice:

> Functions should do one thing only. ... In addition to be easier to comprehend, smaller functions are easier to test in isolation, and now you’ve isolated the orthogonal code into its own function, its name may be all the documentation required.

Using single-caller functions as a substitute for comments makes the workings of a specific operation much harder to follow, as you have to jump around the source to understand its effects.

A long function is easier to understand than an exploded one.

Also tests should target specific operations (aka functional tests), not every single function in the program.

EDIT: Every function you add becomes part of your internal API. Any API, exported or not, should comprise a cohesive collection.

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

#39
I'm not a Go user myself, but I skimmed through the document. What I found was a lot of good programming advice that is generally applicable, rather than being limited to the Go language. (It seems most of the Go-specific stuff is in section 5.) It's always good to see robust coding practices being promoted, regardless of language.

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

#40
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?

I'm wrestling with this at work right now and the short names don't really bother me as they are right in that the fact that if you have the type the shorter name can make the code easier to read slightly. What annoyed me is that for those single letter names I always got collisions so my naming was inconsistent. I personally ended up doing medium length names (like conf) except for the case where there was only 1 local variable (and sometimes if there were two or three) because in that case there were no collisions and what that variable was is very very clear
Post reply on HN