... | ... | @@ -73,6 +73,10 @@ Any dead code (both files that are unused and blocks of commented-out code) shou |
|
|
|
|
|
Stork's backend is implemented in Golang, and we strive to follow the [Effective Go](https://go.dev/doc/effective_go) guidelines to write the idiomatic code. The developers should generally respect these guidelines unless it is stated otherwise below.
|
|
|
|
|
|
## Indentation
|
|
|
|
|
|
We use tabs for indentation in Golang because it is the widely adopted and recommended convention.
|
|
|
|
|
|
## Formatting
|
|
|
|
|
|
Stork build system provides the `rake fmt:backend` command to format the Golang code automatically. You SHOULD run this command to ensure the code adheres to the formatting style. In addition, you SHOULD run the `rake lint:backend` command checking that the code passes the linter checks. The code having any formatting or linter issues cannot be merged.
|
... | ... | @@ -195,12 +199,6 @@ Use all all-lowercase characters for file names. Use dash as a separator (e.g. s |
|
|
|
|
|
The project kicked off in 2019. FullHD is ubiquitous with large 4K displays are getting common. In the general case, the code should have no more than 128 columns. This is let developers display two panels side by side. In some exceptional cases (such as URL), the code may be extended to 160 columns, but this should be rare occurrence.
|
|
|
|
|
|
## Tabs & Indentation
|
|
|
|
|
|
Do not use hard tabs.
|
|
|
|
|
|
Indentation at each level is 4 spaces for C++, other languages should use what is "usual and expected."
|
|
|
|
|
|
## Naming
|
|
|
|
|
|
Don't start things with underscores.
|
... | ... | |