Organization of sources files
-
I am working on a pretty big project and I didn't find a solution which completely convinced me to organize the files.
MyProject
-src
-bin
-include
-lib
-etcThe issue is to organize the src files into subfolders.
I started to have 2 folders one for the GUI one for the CORE but I do have too many files now and it is a big mess. Do you think grouping by functional blocks could be a bad idea (thus, not separating the GUI files from the CORE files)?src :
-car
car.hpp
car.cpp
GUIcar.hpp
GUIcar.cpp
Other.hpp
Other.cpp, etc ...
-
It can be whatever works for you. However, it is often a good idea to "encapsulate" different functional groups as it makes it easier for someone un-familiar with your code base to workout what is going on. For examples you only have to look at the Qt libraries themselves to see how they have sub-foldered (not sure that is a word?) the project.
QtGui/...
QtWidgets/...
QtCore/...
etc...It is often the choosing what is a functional group that is the trick! :o
What groups do you have? -
Yeah I completely agree with you about the fact that the challenge is to find the good groups :D
It's a music desktop app, I have a composition tab, each tab contains atreeWidget with instruments, a note vizualizer, a player, etc ...
For example I needed 15 classes just for the treeWidget (by subclassing all the Qt Widgets that I needed, it is growing very quick ...)
My code is very OO and the best representation is clearly a Tree but its is not convenient to organize folders in a big tree. -
Then you can just do the top level folder (or at most top two levels). I usually, even for large projects, try to keep just one level of depth. More then that and you start to lose clarity rather then gain it!
Again, the Qt example is a good one. It generally has only one level of depth, but it has very many functional groups (I believe linux and other large projects are more-or-less then same).
So its ok to have a treeWidget group with 15 (or even 100) files in it.
As an example from what I have read, you could have:
- ui/ - Contains just the forms/windows in the UI - i.e. just the bits that the user actually interfaces with
- atreeWidget/ - with all its files
- anotherWidget/ - just an example
- player/ - all the items needed for the player
etc... each group can have many files/classes but name them well, so you can have sub-group name schemes, e.g. under player (I am making it up):
- player/encoderAmr.cpp
- player/encoderPcm.cpp
- player/decoderAmr.cpp
- player/decoderPcm.cpp
etc...
-
thank you code_fodder is looks good like this :)
-
np :)