适当的方式来组织/结构化Go包的文件夹和文件是什么?

huangapple go评论83阅读模式
英文:

What is the proper way to organize / structure Go package folders and files?

问题

我知道这可能有争议,或者不是很广泛,但我会尽量具体并与其他问题相关。

好的,当我编写Go程序时,我应该考虑如何组织我的项目?例如,我应该考虑我将要有某种控制器,所以我应该有一个控制器子目录来处理这个,我应该这样做吗?

我应该如何构建一个包的结构?

例如,我目前正在使用这个包来制作一个SteamBot

但是在编写时,我不知道是否应该将某些方法导出到它们自己的文件中,例如,我会有类似这样的东西:

func (t *tradeBot) acceptTrade() {}
func (t *tradeBot) declineTrade() {}
func (t *tradeBot) monitorTrade() {}
func (t *tradeBot) sendTrade() {}

每个方法都会有相当多的代码,所以我应该将每个方法导出到它们自己的文件中,还是只在一个文件中有3000行代码?

另外,我是否应该使用全局变量,这样我可以设置一个变量然后离开它,并能在多个函数中使用它,还是这样做不好,应该将变量作为参数传递?

另外,我应该按照以下顺序排列我的文件:

package
imports
constants
variables
functions
methods

还是只是根据需要放置它们?

英文:

I know this might be controversial or not very broad but I'm going to try to be very specific and relate to other questions.

Ok so when I make a Go program what things should I be thinking in terms of how I should organize my project? (E.g. should I think ok I'm going to have controllers of some sort so I should have a controller subdirectory that's going to do this so I should have that)

How should I structure a package?

For example the current program I'm working on I'm trying to make a SteamBot using this package

But while I'm writing it I don't know if I should export certain methods into their own own files, e.g. I'd have something like

func (t *tradeBot) acceptTrade() {}
func (t *tradeBot) declineTrade() {}
func (t *tradeBot) monitorTrade() {}
func (t *tradeBot) sendTrade() {}

each method is going to have quite a bit of code so should I export each method into its own file or just have 1 file with 3000 lines of code in it?

Also using global variables so that I can set one variable and then leave it and be able to use it in multiple functions, or is this bad and I should pass the variables as arguments?

Also should I order my files like:

package
imports
constants
variables
functions
methods

Or do I just put things where I need them?

答案1

得分: 4

寻找灵感的第一个地方是Go标准库。Go标准库是一个很好的指南,展示了“好”的Go代码应该是什么样子的。虽然库和应用程序不完全相同,但它绝对是一个很好的入门指南。

一般来说,你不需要将每个方法都拆分到单独的文件中。Go更倾向于使用涵盖一个主题的较大文件。3000行似乎相当大,即使是net/http的server.go,也只有2200行,而且已经很大了。

在Go中,全局可变变量和其他任何语言一样糟糕。由于Go非常依赖并发编程,全局可变变量非常糟糕。不要这样做。一个常见的例外是sync结构,比如sync.Poolsync.Once,它们有时是包全局的,但也被设计为可以并发访问。有时还会有结构的“默认”版本,比如http.DefaultClient,但你仍然可以将显式的结构传递给函数。再次,浏览Go标准库,看看什么是常见的,什么是罕见的。

英文:

The first place to look for inspiration is the Go standard library. The Go standard library is a pretty good guide of what "good" Go code should look like. A library isn't quite the same as an application, but it's definitely a good introduction.

In general, you would not break up every method into its own file. Go tends to prefer larger files that cover a topic. 3000 lines seems quite large, though. Even the net/http server.go is only 2200 lines, and it's pretty big.

Global mutable variables are just as bad in Go as in any language. Since Go relies so heavily on concurrent programming, global mutable variables are quite horrible. Don't do that. One common exception is sync structures like sync.Pool or sync.Once, which sometimes are package global, but are also designed to be accessed concurrently. There are also sometimes "Default" versions of structures, like http.DefaultClient, but you can still pass explicit ones to functions. Again, look through the Go standard library and see what is common and what is rare.

答案2

得分: 1

希望以下几点小建议对你有用:

  • 将代码按功能而不是按层次组织到多个文件和包中。随着应用程序规模的增大,这一点变得更加重要。将一个或两个控制器放在controllers包中可能还可以,但将数百个不相关的控制器放在同一个包中是没有意义的。以下文章很好地解释了这一点:http://www.javapractices.com/topic/TopicAction.do?Id=205

  • 全局变量有时可以使代码更容易编写,但是它们应该谨慎使用。我认为对于像日志记录器、调试标志等这些未导出的全局变量是可以接受的。

英文:

Just a few tips that you hopefully find useful:

  • Organize code into multiple files and packages by features, not by layers. This becomes more important the bigger your application becomes. package controllers with one or two controllers is probably ok, but putting hundreds of unrelated controllers in the same package doesn't make any sense. The following article explains it very well: http://www.javapractices.com/topic/TopicAction.do?Id=205

  • Global variables sometimes make code easier to write however they should be used with care. I think unexported global variables for things like logger, debug flags, etc are ok.

huangapple
  • 本文由 发表于 2015年9月17日 06:56:10
  • 转载请务必保留本文链接:https://go.coder-hub.com/32620086.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定