coding-style - 简短的变量声明会导致Go中的代码结构不良吗？

Question

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。

6年前关闭。



Improve this question




通过在GitHub上查看大量Go代码，我注意到Go编码人员喜欢简短的变量声明( :=)，并且经常使用它。这是一个示例 Coding Style。但是，这种用法似乎常常会创建结构不良的代码:非常长的函数将很多功能捆绑在一起，因为 Short variable declarations may appear only inside functions.如果要建立一个封装，该封装将类似于类的东西封装在一起，并且成员需要几个简短的模块化函数进行操作，因为良好的结构化编程和OOP实践要求，您不能真正有效地对成员变量使用简短的变量声明。每当我看到任何超过10或15行的函数时，我都会感到不安-我知道该设计可能不正确。

就个人而言，除了循环计数器等的局部初始化外，我不喜欢使用短变量声明。除了上述问题之外，我还想清楚地看到正在使用的类型。特别是在查看新代码时，简短的变量声明假定读者知道初始化变量的函数将返回什么，或迫使他们去查找或从上下文中推论得出。因此，该代码变得不那么可读，需要读者停止，并可能在某处搜索其含义，而 var声明可能会立即使事情变得清晰。

(我想写更好的代码并仍然使用短变量声明的一种方法是避免完全使用程序包全局成员并参数化所有函数-不一定是一件坏事-但这可能比使用短变量节省的工作更多声明。)

结果，我一直选择对我的软件包使用这种设计，类似于在传统的OOP语言(例如Delphi和C++)中声明和初始化的方式:

package myPackage

import (
    "importA"
    "importB"
)

var m_member1 *importA.T
var m_member2 *importB.T

func init() {

    m_member1 = new(importA.T)
    m_member2 = new(importB.T)

}

然后，我明确地键入，初始化和封装了可在包中使用的包成员。是的，这确实违反了仅在必要时进行初始化的良好做法，但是我也不必在init()中执行此操作-可以在需要时进行首次使用成员时进行初始化，尽管那样还有其他潜在的并发症。 (正因为如此，由于在 constructor中初始化类成员已经很长时间了，所以无论如何我对此没有太大问题。)

Go中的这种非惯用的“不良”代码吗？短变量声明的大量使用及其对IMO的负面影响是否被认为是一件好事？坦白说，我看不出情况如何。我倾向于认为只是喜欢短语法的程序员可能过多使用了短变量声明，其结果是出现了许多肿的意粉样式代码。我想念什么吗？

编辑:由于陈述的问题引起了很大的混乱，我将尝试用一个简单的例子来说明(此文件可能会编译也可能不会编译-只是为了说明而迅速编写)

如果我写:

package main

import
(
"packageA"
"packageB"
)


func DoStuff(){

    a:=PackageA.T
    a.Dostuff()

    }

然后，继续并编写将非常容易:

func doStuff(){

    a:=PackageA.T
    b:=PackageB.T
    Dostuff(a)
    DoMorestuff(b)
    DoEvenMorestuff(a,b)
    DoLotsofstuff(a,b)

    .....


    }

func main(){
  DoStuff()
}

IMO捆绑、,肿，结构不良的代码。

______________________

但是当我写

package main

import

(    "packageA"
    "packageB"
)


var  a packageA.T
var  b packageB.T

init(){

    a=new(packageA.T)
    b=new(packageB.T)

}

Then I can write:

func dostuff(){

    a.Write()

 }

func doMorestuff(){

    b.Write()

 } 


func  doEvenMorestuff(){

  a.Read(b)

  }


func doLotsofstuff(){

 a.ReadWrite(a,b)
 b.WriteRead(b,a)

}

func main(){

  dostuff()
  doMorestuff()
  doEvenMorestuff()
  doLotsofstuff()

}

模块化的管道样式设计，不能使用短变量声明形式实现。使用简短形式可以做到的最好是嵌套的参数化函数，这些函数通常也不是很好的设计选择。

一些人抱怨说这相当于全局变量，但是在一个设计精巧，具有最小 public 接口的封装包中，这与声明函数局部变量无关。包应该是原子的。成员变量一直是OOP设计的公认组成部分，“永远”，并且按照OOP和结构化编程的规则正确使用时，它们不是全局变量，而是封装它们的包或模块或类的局部变量。

当然，没有任何语言的功能无法使用或滥用。我的问题很简单，就是短变量声明似乎已经为滥用而成熟，并迫使某些设计决策不合需要，除非谨慎使用。我在问是否有一种方法可以使用表格来规避我遇到的问题，并为我提供易于使用且没有缺点的表格。

编辑2:

也许这是一个折衷方案:

package main

import

(    

 "packageA"
 "packageB"

)


  func dostuff(a PackageA.T){

    a.Write()

 }

func doMorestuff(    b PackageB.T ){

    b.Write()

 } 


func  doEvenMorestuff(a a PackageA.T, b PackageB.T ){

  a.Read(b)

  }


func doLotsofstuff(a a PackageA.T, b PackageB.T ){

 a.ReadWrite(a,b)
 b.WriteRead(b,a)

}


func doStackofStuff(){

    a:=PackageA.T
    b:=PackageB.T

    dostuff(a)
    doMorestuff(b)
    doEvenMorestuff(a,b)
    doLotsofstuff(a,b)


}

    func main(){

     doStackofStuff()

}

仍然捆绑在 main()中，但这并不是真正的抱怨- doStackofStuff()是我的接口调用。在“真实代码”中，我将为所有代码编写一个单独的程序包，只有 DoStackofStuff()是 public 的，并且可以从 main()进行调用-其余的将被封装。该实现以 doStackofStuff()分解，但使用的是简短形式而不嵌套。

最佳答案

我认为您在这里混合了一些没有联系的问题:

如果您需要在Go中模拟类和结构-请勿为其使用模块。使用结构。为他们建立“构造函数”。而已。即使它与C++或Java类不是100％相同，我什至都不会称其为仿真。我的意思是，为什么不做类似的事情

type Foo struct {
    Bar string
    Baz int
}

func NewFoo(bar string, baz int) *Foo {
    return &Foo{
        bar,
        baz,
    }
}

//and if you want static state - just do this
var DefaultFoo *Foo

func init() {
    DefaultFoo = NewFoo("foo", 1)
}

我不完全明白为什么在函数内部执行:=会创建意大利面条代码。您能在这方面说清楚点吗？如果您不小心，它可能造成的最大危害是范围冲突-如下例所示:

var x int = 3

func main() {
    if x == 3 {
        x := 5
        fmt.Println(x) // will print 5
    }

    fmt.Println(x) //will print 3

}

回到您的示例-从其他模块导入类型的设计也不错(例如，在模块的init()函数中启动了静态http客户端)。但是您必须确保您确实没有在两个软件包之间混淆责任。

关于coding-style - 简短的变量声明会导致Go中的代码结构不良吗？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22809550/

上一篇：parsing - 为什么在 Go 中使用 := with fmt. Scanf 总是返回 1？

下一篇：json - 读取外部 JSON 文件

相关文章：

go - 使用Openshift/Client-go进行Openshift API查询

http - GO 结构文字中的未知 http.Transport 字段 'ExpectContinueTimeout'

c - 结构初始化失败

java - 在构造函数中初始化私有(private)变量

java - 一种避免 JSP 和 HTML 标记语法模糊(<、/和> 字符)的方法？

coding-style - 我可以写 {x,a,b}//Do[...,#]& 而不是 Do[...,{x,a,b}] 吗？

python - python中物理量的命名

java - 如何让 Maven 检查源行尾？

bash - 如何使用 Go 在命令行上执行 diff？

Delphi:可以有条件地进行单元初始化吗？

Answer 1

我认为您在这里混合了一些没有联系的问题:

如果您需要在Go中模拟类和结构-请勿为其使用模块。使用结构。为他们建立“构造函数”。而已。即使它与C++或Java类不是100％相同，我什至都不会称其为仿真。我的意思是，为什么不做类似的事情

type Foo struct {
    Bar string
    Baz int
}

func NewFoo(bar string, baz int) *Foo {
    return &Foo{
        bar,
        baz,
    }
}

//and if you want static state - just do this
var DefaultFoo *Foo

func init() {
    DefaultFoo = NewFoo("foo", 1)
}

我不完全明白为什么在函数内部执行:=会创建意大利面条代码。您能在这方面说清楚点吗？如果您不小心，它可能造成的最大危害是范围冲突-如下例所示:

var x int = 3

func main() {
    if x == 3 {
        x := 5
        fmt.Println(x) // will print 5
    }

    fmt.Println(x) //will print 3

}

回到您的示例-从其他模块导入类型的设计也不错(例如，在模块的init()函数中启动了静态http客户端)。但是您必须确保您确实没有在两个软件包之间混淆责任。