Home  >  Article  >  Backend Development  >  Counterexamples that violate golang function best practices

Counterexamples that violate golang function best practices

王林
王林Original
2024-05-03 12:18:01614browse

It is important to follow functional best practices. Avoid the following counterexamples: Functions that are too long Functions without docstrings Output parameters Functions with too many nested functions Return error codes instead of error values

Counterexamples that violate golang function best practices

Violation of Go language functions 5 Counterexamples to Best Practices

When writing high-quality code in Go, it is crucial to follow functional best practices. Avoiding the following counterexamples can help you write maintainable, readable, and efficient functions.

1. Overly long functions

func DoEverything(a, b int, c string, d bool) (int, error) {
    if c == "" {
        return 0, errors.New("c cannot be empty")
    }
    if !d {
        return 1, errors.New("d must be true")
    }
    return a + b, nil
}

Best practice: Break functions into smaller, reusable functions.

2. Functions without documentation string

func DoSomething(x int) int {
    return x * x
}

Best practice: Add a documentation string to each function to explain its purpose and parameters and return value.

3. Output Parameters

func Swap(a, b *int) {
    tmp := *a
    *a = *b
    *b = tmp
}

Best Practice: Avoid using output parameters as it can make the code difficult to understand and debug.

4. Too many nested functions

func Nested(x int) int {
    if x > 10 {
        func inner(y int) int {
            return y + 1
        }
        return inner(x)
    }
    return x
}

Best practice: Move nested functions out of the main function, or use closures.

5. Functions return error codes instead of error values

func OpenFile(name string) int {
    f, err := os.Open(name)
    if err != nil {
        return -1
    }
    return f.Fd()
}

Best practice: According to Go language conventions, functions should return error values, instead of an error code.

Practical case

Consider the following function that needs to convert a list into a dictionary:

// 不遵循最佳实践的示例
func ConvertListToDict(list []string) map[string]bool {
    dict := make(map[string]bool)
    for _, v := range list {
        dict[v] = true
    }
    if len(dict) != len(list) {
        return nil
    }
    return dict
}

This function has the following problems:

  • The return value is nil, but the docstring does not describe this situation.
  • The function does not handle duplicate elements, and there is also ambiguity in returning nil.

Example of following best practices

// 遵循最佳实践的示例
func ConvertListToDict(list []string) (map[string]bool, error) {
    dict := make(map[string]bool)
    for _, v := range list {
        if _, ok := dict[v]; ok {
            return nil, errors.New("duplicate element in list")
        }
        dict[v] = true
    }
    return dict, nil
}

This function solves the above problem and returns an error value for duplicate elements.

The above is the detailed content of Counterexamples that violate golang function best practices. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn