[Merged by Bors] - Add CODING.md

[acud]

Motivation

As a part of an effort to standardize the way we develop software I am suggesting this as an entry point to a discussion about how to write and expect code to be checked into the codebase.

Description

While a lot of the suggestions here don't match what is actually in the codebase, it is meant to describe the point we aspire to get to, and slowly mutate the codebase into that direction by altering what is already there or by the style in which new components are written. It is meant as a departure point into a discussion about the content, rather than an attempt to coerce the content as something set in stone, therefore, suggestions and questions are welcome.

Test Plan

Not to achieve a quorum but to see if anyone in the team objects to this format and content.

[fasmat]

Thanks for providing a great starting point for this! 🙂

Overall I agree with the suggested coding style. I added a few comments regarding details that I'm unsure about or feel like could be added to the document.

[fasmat]

Should we add to use the general pattern of using switch and errors.Is/errors.As like:

var customError MyErroType
err := someFunctionCall()
switch {
case errors.Is(err, Error1):
   // handle Error1
case errors.As(err, &customError):
   // handle customError
case err != nil: // another error
   // handle generic error
}

or leave that up to the developer?

[acud]

I think that using errors.Is/As should be encouraged yes. About using switches - I'm not 100% sure because it's a general deviation from the usual if err := ... {} structure and switches have the problematic aspect of when they have the default: case it would handle the happy path which is a bit misleading. Ideally, the happy path should never be nested, but rather handled at the base nesting level of the method (only error paths should be nested). It is indeed sometimes unavoidable to handle happy path this way but switches may cause this to happen more often than not.

Also as a sidenode it should probably also be noted that happy path shouldn't be nested :)

I'd like to cover all those in a separate styleguide that would have examples too.

[poszu]

Using switch doesn't mean that the happy path must be nested. The errors can be handled in the switch cases and the happy path - below:

err := someFunctionCall()
switch {
case errors.Is(err, Error1):
   // handle Error1
case err != nil:
   // handle unknown error
}

// happy path goes here

[acud]

I've addressed most of the comments here, please see the diffs that I've pushed. I suggest to address specific style-guide points in a separate document that will be more detailed.

[fasmat]

lgtm, if @ivan4th and @poszu have no objections, I'd say its ready to be merged and go into effect 🙂

[acud]

bors merge

[spacemesh-bors]

Pull request successfully merged into develop.

Build succeeded:

• ci-status
• systest-status