Code readability

The most obvious characteristic of code is how it's easy to read. Build habit to write readable and understandable code needs as early as possible. It is not only about you as a responsible team member, but also reduce bugs and bugs fix time.

Naming

Variables, function, classes, namespaces, packages, configuration file settings and other things that can be named, should very accurate reflecting their role inside giving context. User can have different roles relative to contexts such as: customer, receiver, purchaser etc. Inside any context user should have appropriate name, even if only one user in given context.

This rule is suitable for local variables with short life cycle. Even if variable contains value from one function and passes it to other function on next line, it should reflect business role of its value.

Exception to the rule are used loop iterators called i,j etc. Because they are technical variables, and it's not contained in business logic. Short names reduce complexity inside construction that already not elementary because executed multiple times.

1// What do you think the function does?
2// You have to read every line to answer
3func calc(n int) string {
4    b := make([]byte, n)
5    for i := 0; i < n; i++ {
6        b[i] = byte(65 + rand.Intn(90-65))
7    }
8    return string(b)
9}

 1// This is the same function
 2func getRandomString(length int) string {
 3    const minChar = int('A')
 4    const maxChar = int('z')
 5
 6    bytes := make([]byte, length)
 7    for i := 0; i < length; i++ {
 8        bytes[i] = byte(minChar + rand.Intn(maxChar-minChar))
 9    }
10    return string(bytes)
11}

Function length

Count of function bugs correlates with counts of lines.

There are studies about this correlation, but any concrete numbers do not matter. Common rule says that functions should be small.

Function length as well relative to complexity of the functions. If you can't keep in mind all about every variable in the function you maybe should split it.

Recommended to check function complexity not after development, but after some time, before committing to version control system.

When you already out of the context of the method task.

Reduce nesting

Need to avoid deep nesting with conditions and loops. Sometimes it's not possible, but you can wrap inner conditions or loops to separate functions.

 1// Сomplex function
 2func Foo(){
 3    if condition_1 {
 4        if condition_2 {
 5            if condition_3 {
 6                return
 7            } else{
 8                return
 9            }
10            return
11        }
12        return
13    }
14    return
15}

 1// Simple functions
 2func Foo(){
 3    if condition_1 {
 4        return Bar()
 5    } 
 6    return
 7}
 8
 9func Bar(){
10    if condition_2 {
11        return Baz();
12    } 
13    return;
14}
15
16func Baz(){
17    if condition_3 {
18        return;
19    } else{
20        return;
21    }
22}

Constants instead of values

Even if the value used in one place and will never change, not use value in code. Every developer should be able to understand the meaning of a value and why it's exactly this.

1// What are this numbers meen?
2func randomChar() byte {
3    return byte(65 + rand.Intn(122-65))
4}

1// return random alphabetic char
2func randomChar() byte {
3    const minChar = int('A')
4    const maxChar = int('z')
5    return byte(minChar + rand.Intn(maxChar-minChar))
6}

Comments are not about readability

Comments don't compensate unreadable code (except performance reasons). Developers will not actualize comments after changes, as a result after that the comment will cause errors and disinformation.

Comment should be used for describing reasons of function implementation when it can't be described in code.

sdsd

---