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.
Practical Go: Real-world advice for writing maintainable Go programs
31–40 of 237 posts
Re: Practical Go: Real-world advice for writing maintainable Go programs
#32Earlier 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…
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
#33Re: Practical Go: Real-world advice for writing maintainable Go programs
#34Re: Practical Go: Real-world advice for writing maintainable Go programs
#35> 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> 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
#37> 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
#38> 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?
> 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
#39Re: Practical Go: Real-world advice for writing maintainable Go programs
#40> 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?