我有一个代码库，其中一个文件包含相当多的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