I recently wrote a small webservice with some db-operations and some webcrawler functionallities.
The DB part consists of an abstraction of my DB. Every table is represented in the code as a struct to work “directly” on the db. This part is about 1000 lines of code
The crawler functionality is about 500 lines of code.
All in all my go file is roughly 2000 lines of code long.
I know that it is not uncommon to have very large go files, but would you serparate these project into the packages (service/db/crawler)?
I would separate them into files. One for main, one for the crawler, and one or more for the db stuff.
Okay, thats what my first idea was.
Coming from the java world I thought about creating a new file for every db abstraction object. But I’d say that’s not the go way.
Just use a natural organization. Your initial question already laid that out with the “DB part” and the “crawler functionality”. Once those are split out, you would have found
main and the other start-up code (config handling, etc.).
My rule of thumb for splitting up a large file is to use imports as a guideline. That is, all the things that import network stuff go in one file, all the thing importing strings/regex and parsing go in another and so on.
This tends to also make testing more straight forward. If you have a file, say, conn.go, that deals with network type stuff, then its counterpart conn_test.go should deal only with testing the network behaviour of this package. If you didn’t you’ve got parsing or business logic tests in that file as well, that’s a sign that your design isn’t right, or that you carved your file along the wrong boundary.
Obviously some judgement needs to be applied as packages like fmt and errors tend to be used everywhere.
Also, don’t take this to the extreme and split too much, otherwise you’ll replace the problem of a large file with the problem of constantly searching a directory of files. If your package starts to look like Java, with one function or type per file then you’ve gone to far and it’s time to consolidate.
Again imports help guide you here, if you find two files with identical imports and related functionality, then try meeting them.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.