Add a coding style guide

[johananl]

This PR adds an initial code style guide for Lokomotive. The guide currently focuses mainly on Go code, however we could add guidelines for other types of code (e.g. HCL, Markdown).

I find it useful to maintain such a guide as I find myself commenting the same things over and over again in PRs and would love to have a document I could link to. I think that following a common and agreed-upon guide could make code reviews more efficient.

The document should be agreed upon by the team and is expected to evolve over time. The current state is by no means a comprehensive list of guidelines. Rather, it currently contains a small set of initial guidelines which I believe already have consensus in the team so we might as well formalize them.

[invidian]

@johananl did you see #883?

[invidian]

Great start @johananl!

[johananl]

@johananl did you see #883?

Nope, thanks for the pointer. I'm deliberately avoiding adding all the guidelines we know about from the start. Rather, I wanted to start by merging something simple and encourage the team to add more guidelines as the need arises.

[invidian]

LGTM ✔️

[iaguis]

Thanks! LGTM.

[surajssd]

LGTM

[knrt10]

Thank you for adding this. +1

[ipochi]

minor suggestion but LGTM.

Great start @johananl

[rata]

Mostly LGTM.

The only thing I'm unsure about is the errors. I'm unsure if errors won't become cryptic or if we will simply have ton of review comments on error fromatting without much benefit.

Is there any other project using that style rule for errors? I guess from the blog post example maybe the go project itself?

[johananl]

The only thing I'm unsure about is the errors. I'm unsure if errors won't become cryptic or if we will simply have ton of review comments on error fromatting without much benefit.

Not sure I got your point. What change are you suggesting? Removing the guidelines about errors?

Is there any other project using that style rule for errors? I guess from the blog post example maybe the go project itself?

There is https://github.com/golang/go/wiki/CodeReviewComments#error-strings if you're looking for an official recommendation. But it also just makes sense IMO because error strings are chained. These guidelines produce consistently-formatted, readable errors.

[rata]

Not sure I got your point. What change are you suggesting? Removing the guidelines about errors?

Yes, that can be simpler. But no problem, we can remove it later if we find that it creates overhead and little benefit :)

[johananl]

Not sure I got your point. What change are you suggesting? Removing the guidelines about errors?

Yes, that can be simpler. But no problem, we can remove it later if we find that it creates overhead and little benefit :)

I've added only things which I've found myself constantly commenting on in PRs. That was actually the trigger for me starting this document. IMO not having guidelines for error strings is what's causing overhead. But anyway - sure, the idea is to evolve this doc over time and of course if some guideline proves to be counterproductive we should revisit.

[johananl]

Thanks to everybody who chimed in. I will merge this since we don't seem to have any major disagreements around the content.
Please feel free to propose new additions or modify existing guidelines in new PRs.