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

Post by networkimprov » Thu, Feb 21, 2019, 10:08 PM UTC

jjuel wrote: post #100

networkimprov wrote: post #38

Earlier quoted context omitted.

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 a…

Longer functions are much more prone to causing errors, and errors that are harder to find. It is honestly much better to have functions that do one thing and one thing only. Might not always be possible, but it is always the best way to code.

Post by zbobet2012 » Thu, Feb 21, 2019, 10:12 PM UTC

networkimprov wrote: post #38

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?

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 a…

  func ManyThing(i int) int {
   fmt.Println(i)
   return i+1
  }

Post by axaxs » Thu, Feb 21, 2019, 10:17 PM UTC

amedvednikov wrote: post #30

kochthesecond wrote: post #28

Earlier quoted context omitted.

Hi, never heard of V before. Looks great. What are the cons? No runtime and such a small language! How does it do threads? Networking? Any story on cross-compiling?

The main con is it's at a very early stage. It supports only traditional threads right now (but with automatic locking). Networking is supported. It uses curl/windows api. Cross compiling will be top notch, just like with Go.

Post by hactually » Thu, Feb 21, 2019, 10:22 PM UTC

johnisgood wrote: post #104

I don't understand something. > 5.1. Consider fewer, larger packages > 5.2. Keep package main small as small as possible If you have one package, which is the main package, then how are you supposed to keep it small, and at the same time not creating more packages because somehow that is the work of the devil? He is telling me to try to fit everything into one package, but at the same time keep it really small. It is…

Post by SaltyBackendGuy » Thu, Feb 21, 2019, 10:39 PM UTC

networkimprov wrote: post #70

Scramblejams wrote: post #66

Earlier quoted context omitted.

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() { ... } }

    function fDing() {
      ...
    }