... | ... | @@ -71,7 +71,25 @@ Any dead code (both files that are unused and blocks of commented-out code) shou |
|
|
|
|
|
# Go Style
|
|
|
|
|
|
Used by backend server and agent. We use the syntax recommended by `go fmt` command. Please make sure your code adheres before you submit it for review. One way to run the formatted is: `rake fmt:backend` and `rake lint:backend FIX=true`.
|
|
|
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.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
## File Names
|
|
|
|
|
|
The `.go` file names should reflect their contents. For example, if a file mainly contains the code modelling a subnet and defining some operations on the subnet, the `subnet.go` is a suitable name. The relevant unit tests should be in the `subnet_test.go`. If multiple words are needed to describe the contents (e.g., modelling a shared network), the appropriate file name SHOULD contain multiple words without any separator (e.g., `sharednetwork.go`). The relevant unit tests should be in `sharednetwork_test.go`.
|
|
|
|
|
|
Non-golang files can contain underscores as separators.
|
|
|
|
|
|
## Package Names
|
|
|
|
|
|
When you create a new type (e.g., a structure) in a package, you should consider how this name will appear together with the package name. It is a common mistake to give an elaborate structure name without thinking that the fully qualified name will contain repeated words from the package name. For example, the `keaconfig` package contains a `Subnet` structure. You can refer to this structure from another package like this: `keaconfig.Subnet`. It is brief and clear. It indicates that the subnet is a part of the Kea configuration.
|
|
|
|
|
|
Adding a more descriptive name to the `Subnet` structure can be tempting, but let's see how it can look together with the package name. Suppose you name the structure `KeaSubnet`. You'll refer to it `keaconfig.KeaSubnet` from another package. The word `Kea` is redundant and makes the reference less readable. The word `kea` in the `keaconfig` already indicates that the subnet belongs to Kea, so there is no need to repeat it in the structure name.
|
|
|
|
|
|
It is ok to have the same structure name in multiple packages because the package names differ. For example, we already have `keaconfig.Subnet` and `dbmodel.Subnet`. The structure name is the same but they are two different objects.
|
|
|
|
|
|
# TypeScript Style
|
|
|
|
... | ... | |