Create code style guide for Go, Terraform and Helm

[invidian]

To avoid the same discussions over and over on the pull requests, we should create a style guide for Go and Terraform code, which should cover opinionated decisions about the code style in our code base. We should discuss and agree on things which are added here, to make sure everyone is satisfied and is comfortable following those style guides.

The style guide should include aspects, which are not covered by the linters. However, if we get time to do so, we could implement the style guide in a linter to make sure it is enforced automatically.

Some items, which could go there:

• Controlling execution flow using logger (Don't use logrus Fatalf() method #630)
• Preferring fmt.Errorf over errors.New() or errors.Wrapf() (Update error wrapping to new Golang conventions #59)
• Preferring underscores over dashes in Terraform resource names: (Use underscores instead of dashes in Terraform names #622)
• Always decorating returned errors with fmt.Errorf() unless function returns error only once.
• Decorating last error check and returner error if function has less than 4 return statements.
• Putting error'ous function call into same line as if statement, if err is the only parameter assigned, unless it violates line length linter recommendations.
• Always documenting unexported functions.
• Always capitalize code comments, make them proper statements and finish with dot.
• In HCL structs, put computed fields at the bottom of the struct.
• Errors in HCL diagnostics should be checked using HasErrors() method.
• //nolint:foo vs // nolint:foo vs // nolint: foo
• Capitalization of errors in test suite (t.Fatalf("failed to bla") vs t.Fatalf("Failed to bla"))
• Putting //nolint: funlen inlined with function declaration

  func foo() { //nolint: funlen

  vs

  //nolint: funlen
  func foo() {

• (Don't) use make for initializing slices.

  var foo []string // 

  vs

  foo = make([]string, 0)

  vs

  foo = new([]string{})

  vs

  foo := []string{} // Most popular case it seems.

• Name Go test files like described in prometheus-operator: Add external_url #964 (comment)

CC @iaguis

[surajssd]

(Don't) use make for initializing slices.

What is the rationale behind this?

[surajssd]

Also blindly following consistency is not something we should do. There are two ways to do things in golang because both ways has their importance.

For the sake of hard consistency there is no point in trading performance wins.

Also these code guidelines should not become coding bible of the project. They should be guidelines to follow in "most cases", not always.

[invidian]

(Don't) use make for initializing slices.

What is the rationale behind this?

To make code more consistent and predictable as for any other item on the list.

For the sake of hard consistency there is no point in trading performance wins.

We don't shuffle tons of data trough our code, we do not run a webserver which needs to optimize on CPU, memory usage and latency, so I doubt the performance of code should be in our focus. However, obviously, if something needs to be optimized, then this is a special case. But I'd prefer consistency over premature optimization.