我有一個代碼庫，其中一個文件包含相當多的Structs，Interfaces和Variables與函數位於同一個文件中，我不確定是否需要將它分離爲單獨的附加文件名的文件。因此，例如accounts.go將分別爲accounts_struct.go和accounts_interface.go，分別帶有結構和接口。Golang - 具有結構體，變量和接口的代碼組織
當您爲Structs，Variables和Interfaces增加代碼庫時，對文件組織來說什麼是一個好方法？
一個好的模型，以檢查出是圍棋本身的源代碼：http://golang.org/src/pkg/
你會看到，這種方法（基於類似結構，界面語言項目分開，...）從未使用過。
所有文件都基於功能，最好使用鄰近原則方法，您可以在同一個文件中找到您正在使用的定義。
一般情況下，這些功能都在每包一個文件分組，除了大的，其中一個包裹是由許多文件（net，net/http）
如果你想單獨什麼，分開源（xxx.go）從tests/benchmarks（xxx_test.go）
太棒了！將Structs放置在頂部還是正上方最好？ – 2014-10-07 06:38:16
@PassionateDeveloper我更喜歡頂層，定義我使用的各種類型（struct，func，aliases，...），特別是如果這些是公共類型（帶有大寫字母）。但對於內部私有類型（小寫），我在代碼中間定義它們，就在使用它們之前。 – VonC 2014-10-07 06:42:53
@PassionateDeveloper無論如何，golint（https://github.com/golang/lint）和去獸醫是你的朋友。 https://blog.splice.com/going-extra-mile-golint-go-vet/ – VonC 2014-10-07 06:43:19
這是我設計軟件包的心理模型。
a。一個包應該包含一個想法或概念。 http是一個概念，http客戶端或http消息不是。
b。包中的文件應該包含一組相關類型，一個好的經驗法則是如果兩個文件共享同一組導入，則合併它們。使用前面的示例，http/client.go,http/server.go是一個很好的粒度級別
c。不要爲每個類型創建一個文件，這不是慣用的Go。
+1。我同意。這讓我想起了當時在http://stackoverflow.com/a/14870666/6309中發現的一些建議。 – VonC 2014-10-07 07:46:33
我覺得這太寬泛了...但我的建議是考慮你的代碼有什麼知識，看看你是否可以把它分成更小的塊，知識少。不要任意決定將所有結構放在一個文件中，這很奇怪。 – 2014-10-07 05:14:49
到目前爲止，幾乎所有的情況下（除了Web應用程序的前端），我已經能夠將大量代碼劃分爲自包含，可重用的包。你應該看看你的代碼是否可以。 – 2014-10-07 06:20:22