我正在处理一些代码，其中许多函数更新“通过引用传递”的项，沿着下面的DoSomethingB行。作为一个新手，这对我来说相当不直观。我宁愿让一个函数返回它们的结果（除非它可能是一个方法并更新接收者）。
问题：
1.是否有一个好的论据来支持使用DoSomethingB over DoSomethingA这样的模式？
DoSomethingB（不是一个结构体方法）在go中被认为是好的或可接受的风格吗？
package main
import (
"fmt"
)
func DoSomethingA(someData int) int {
return someData + 23
}
func DoSomethingB(someData *int) {
*someData = *someData + 23
}
func DoSomethingC(someData *int) *int {
tmp := *someData + 23
return &tmp
}
func main() {
someDataA := 19
someDataB := 19
someDataC := 19
fmt.Printf("1) someDataA=%d, someDataB=%d, someDataC=%d\n", someDataA, someDataB, someDataC)
someDataA = DoSomethingA(someDataA)
DoSomethingB(&someDataB)
someDataC = *DoSomethingC(&someDataC)
fmt.Printf("2) someDataA=%d, someDataB=%d, someDataC=%d\n", someDataA, someDataB, someDataC)
}Go playground链接：https://play.golang.com/p/ELwljCaWDLg
1条答案
按热度按时间y3bcpkx11#
当然，让我们来分解你的问题：
1.DoSomethingB vs DoSomethingA：如果您想修改原始变量而不创建副本，那么使用像
DoSomethingB这样的模式会很有帮助，从而避免不必要的分配。但是，它可能会导致代码更难理解。使用DoSomethingA，返回结果，在Go中通常更习惯，并且通常更倾向于可读性。1.DoSomethingB在Go中被认为是好的风格吗？：虽然在Go中看到类似于
DoSomethingB的代码并不罕见，特别是在处理大型数据结构时，Go的惯用方式鼓励返回值而不是修改指针。使用指针直接修改值（特别是对于整型等内置类型）可能会导致代码更难理解。示例
DoSomethingC将被认为是unidiomatic的，因为它返回一个指向局部变量的指针。这可能会导致未定义的行为，因为在函数返回后，内存位置可能会重新用于其他内容。最好避免这种模式。总而言之，如果你想遵循Go语言的习惯用法，最好选择像
DoSomethingA这样的模式。如果您有很强的理由修改原始数据，并且性能是一个问题（例如，大型数据结构），那么DoSomethingB可以接受。