Summarize our engineering conventions.

[dpordomingo]

It would be great to summarize our engineering conventions like which logging or testing libraries do we use, how do we handle errors...

For example, I came across with "Choose one log library for Go and implement on all the projects" but I could not find it easily; we also own many big projects using the discarded library, what could lead to misunderstandings.

Not all people know what things do we use when we develop, and I'd find quite useful if all these conventions would be described under guide/engineering

• Logging → Logrus (by https://github.com/src-d/backlog/issues/840#issuecomment-343930191)
• Testing testify or go-check
• Library to use in CLI commands → go-flags
• When to use src-d/go-errors
• CodeReview guidelines for Go → are we following the Go Code Review Comments guide?
  • Code conventions and styles for other langs like Scala, Python, C++ (as suggested by @juanjux)
• Vendoring and dependencies as sugested by @bzz
• CI, CD and building as discussed at code-annotation PR
• How we do continuous delivery for web apps
• Store linter configurations and rules for different languages in src-d/ci
• ...

[eiso]

Great idea!

[dpordomingo]

I added the Go Code Review Comments guide to the issue description in case it is a company-wide recommendation (it is for Apps team)

[eiso]

@mcuadros are you open to a PR from @dpordomingo for this?

[eiso]

@dpordomingo you have the go-ahead from @mcuadros (via emoji above). Would you like to do this?

[dpordomingo]

Oh, for sure I can start working on this, but I'll need tons of help.

(I updated the issue description with vendoring, and building issues)

[juanjux]

Great idea!

Add coding conventions / coding style (for all the languages we mainly use: Go, Scala, C++ and Python) to that list.

For example, we've a Python one somewhere, and also I know we follow Google style for variable/names for C++ (but fortunately not other 💩 points in their coding guide like not using exceptions), but it would be great to have them all linked in this document.

[bzz]

\cc @smola

[smola]

I think I covered the basics in the PR.

Store linter configurations and rules for different languages in src-d/ci

We do not have standarized linter rules, but I think it is a good idea to add them to src-d/ci if/when we have them.