简短的变量声明会导致 Go 中的代码结构不佳吗？

Question

通过查看 GitHub 上的大量 Go 代码，我注意到 Go 编码人员喜欢简短的变量声明 ( :=) 并且经常使用它。这是一个示例编码风格。但这种用法似乎过于频繁，以至于无法创建结构不良的代码：将许多功能捆绑在一起的非常长的函数，因为 短变量声明可能只出现在函数内部。 如果您想建立一个包来封装类似于具有几个短的模块化函数的成员的类的包，正如良好的结构化编程和 OOP 实践所要求的那样，您不能真正有效地对成员变量使用短变量声明。每当我看到任何超过 10 或 15 行的函数时，我都会感到不安 - 我知道该设计可能有问题。就个人而言，除了循环计数器的本地初始化等之外，我不是短变量声明的忠实粉丝。除了上面提到的问题，我喜欢清楚地看到我正在使用的类型。特别是在查看新代码时，简短的变量声明假定读者知道初始化变量的函数返回什么，或者迫使他们去找出，或者从上下文中推断出来。因此，该代码变得不那么可读，需要读者停下来，也许会在某处寻找其含义，而var声明可能会使事情立即变得清晰。（我认为编写更好的代码并仍然使用短变量声明的一种方法是完全避免使用包全局成员并将所有函数参数化 - 不一定是一件坏事 - 但这可能会比使用短变量节省的工作量更多声明。）因此，我一直选择对我的包使用这种设计，类似于传统 OOP 语言（如 Delphi 和 C++）中声明和初始化的工作方式：package myPackageimport (    "importA"    "importB")var m_member1 *importA.Tvar m_member2 *importB.Tfunc init() {    m_member1 = new(importA.T)    m_member2 = new(importB.T)}然后我已经清楚地键入、初始化和封装了可以在包中使用的包成员。是的，这确实违反了仅在必要时初始化的良好做法，但我也不必在 init() 中执行此操作 - 可以根据需要在第一次使用成员时执行此操作，尽管那样有其他潜在的并发症。（尽管如此，由于在 a 中初始化类成员constructor已经很长时间了，我对此没有太大问题，无论如何。）这是 Go 中非惯用的“坏”代码吗？大量使用短变量声明及其 IMO 负面后果是否被认为是一件好事？坦率地说，我不明白它是怎么回事。我倾向于认为，也许只是喜欢简短语法的程序员过多地使用了简短的变量声明，结果是很多看起来臃肿的意大利面条式代码。我错过了什么吗？

Answer 1

答案其实很简单。短变量声明 eg 的唯一替代方法a := 2是长变量声明 eg var a int = 2。

它们中的任何一个是促进意大利面条式代码还是使函数本质上更长？不。