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

Counterexamples that violate golang function best practices

王林
Release: 2024-05-03 12:18:01
Original
644 people have browsed it

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
}
Copy after login

Best practice: Break functions into smaller, reusable functions.

2. Functions without documentation string

func DoSomething(x int) int {
    return x * x
}
Copy after login

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
}
Copy after login

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
}
Copy after login

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()
}
Copy after login

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
}
Copy after login

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
}
Copy after login

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!

Related labels:
source:php.cn
Statement of this Website
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
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template