I'm working on a big project which will likely end up containing tens of thousands of line of code, for the current structure I do like this:
main.go
controllers/NAME.go
models/NAME.go
The problem with that is that the controllers and models directory contains a lot of files, all using package controllers and package models. I was therefore thinking about splitting it up like this:
main.go
controllers/user/NAME.go
models/user/NAME.go
Where the user files in the controllers package might contain files like routes.go, profile.go, etc.
Now, I read that it's bad practice to name packages like controllersUser or controllers_user, but I worry it might be a bad idea to name both as package user since they're a part of the same project (even if they're located in different directories).
What kind of naming structure would you recommend given my situation?
I realize that the files located in controllers/user will not be able to interact with models/user even through they share the same package user name (unless I import of course), and I also know that I can easy import both as userControllers "controllers/user" and userModels "models/user", but I wonder if it's a bad practice to do like this?
I suggest you read style guideline for Go packages. It's a fantastic read and contains the best advice I found on the subject when it comes to project layout in Go. I'm having hard times suggesting you a naming for your specific case though because it depends too much on the kind of functionality your system has. Sometimes, I think of it as a "package per part of the application". But I understand my description may result too personal and not very helpful.