通過查看 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 負面后果是否被認為是一件好事？坦率地說，我不明白它是怎么回事。我傾向于認為，也許只是喜歡簡短語法的程序員過多地使用了簡短的變量聲明，結果是很多看起來臃腫的意大利面條式代碼。我錯過了什么嗎？