Just a quick question, how big is your project? Like... in files. I'm just curious, because mine currently has 80 files and its just the engine. I plan on adding minor features and smoothing things out a bit. This will probably grow to 90 files after that. Once I add the actual game-part back in, it will be over 100. Is that excessive? I try to have a source for every header for completeness. Most of my files have at least a few 100 lines of code. A fair portion of them have 1000+. What's your's like? I have to scroll miles and miles... hehe I hate scrolling ;-)
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
How big is your project?
30-40 files at most, though I'm just a hobbyist. I hate tabbing between files too, and I rarely have to scroll because I don't have to work on many parts of the code at once. Usually the function I'm implementing and maybe the point where I'm using it. If I have to jump here and there in the source code, that means the system is a spaghetti.
Using SourceMonitor, my personal project is:
817 files, containing 113,244 non-empty lines, of which 22.7% are comments, 59,204 are actually code statements / logic, the rest are things like class definitions and so on.
1,140 functions, 750 classes, with an average of 7.93 methods per class. (I guess class functions don't count towards their "function" metric?)
(some GDNetters work on commercial projects that are ten times or even a hundred times larger than this :wacko:)
This is one "project" but it's a large project broken into multiple sub-projects:
- My common library
- Common library test suite (mostly empty :P)
- The game engine
- The huge editor
- The (mostly non-existent) game
- Assorted tiny tools
I've been working on it for six years now, so it's accumulated alot of code. However, I've pruned it regularly, so I've probably deleted at least 50k worth of lines over the years.
When any file gets over two or three thousand lines of code, I consider whether I should break it into more than one .cpp file, just for convenience of editing, and also consider whether that class is trying to do too much.
For example, I have GameStructure.cpp/,h, but because it has three functions that happen to naturally take up alot of lines, I also have GameStructure_LoadAssets.cpp which also just includes GameStructure.h, for the three functions that can't easily/cleanly be broken up and happen to be unwieldy.
If a function gets too large though, it makes sense to refactor it into smaller functions whenever possible. That's why SourceMonitor also tells me: My average lines of code per function is 4.6, and my average scope depth per function is exactly 1.00, with a max depth of... 8 nested scopes. :o I wonder what abomination that is!
[Edit:] Ah, there are two funcs that reach 8 depth: one is a third-party header-only library, and one is a function I wrote for handling events, and each event branch I should've refactored into separate funcs. :ph34r:
Most of my files have at least a few 100 lines of code. A fair portion of them have 1000+. What's your's like? I have to scroll miles and miles... hehe I hate scrolling ;-)
Typical "well engineered" software will end up with many files (corresponding to how many pieces of actual functionality you need) and files will be short.
A file is similar to the next step up from a class. In other words, follow the Single Responsibility Principle. If your files are too long that might mean that your file is doing too much varied stuff and should be broken into more fine-grained purpose-build modules. e.g., instead of a big Renderer.cpp file, consider splitting it into pieces like CommandList.cpp, TextureLoader.cpp, and so on. Your big Renderer class could then just have TextureLoader and CommandListAllocator and such as member variables rather than embedding that logic into the Renderer class itself. In other words, use composition to implement both types and functions.
With modern languages you should also be making much use of genericity. That is, Don't Repeat Yourself. If you write a function to do X and another function to do Y where X and Y are basically the same thing, convert them to a single function. Use templates/generics if you need to, or polymorphism if that makes more sense in the context. Combining duplicate code can result in both shorter files and fewer files. Note that this also applies to your language's standard facilities. Use the STL algorithms in C++ rather than writing your own loops or versions. If you're in Python, make sure you're capitalizing on list comprehensions. If in C#, make use of LINQ. And so on. Coding like a C programmer when you're in a more capable language will result in much more bloated and possibly slower code.
Most of my files have at least a few 100 lines of code. A fair portion of them have 1000+. What's your's like? I have to scroll miles and miles... hehe I hate scrolling ;-)
Typical "well engineered" software will end up with many files (corresponding to how many pieces of actual functionality you need) and files will be short.
What is the correlation between well engineered software and having many files?
I agree with everything you said, but this one I don't know about, especially with pretty much any editor with some navigation features. Possibly I just have no idea what "big" project means.
What is the correlation between well engineered software and having many files?
I agree with everything you said, but this one I don't know about, especially with pretty much any editor with some navigation features. Possibly I just have no idea what "big" project means.[/quote]
It's not so much that well-engineered software will have many files. It's perfectly possible to have a small, well-engineered project with just a few files.
It's more that the number of files scales with complexity rather than the length of the files.
If you look at a project and it's 200,000 LoC and there are on 50 files.... that's a worry. (Side note: from a productivity pov, this is especially worrying in a language like C++ where file length can impact build time).
Even if the IDE allows for easy navigation within the file, it still means that you have almost certainly violated SRP for a module.
Typical "well engineered" software will end up with many files (corresponding to how many pieces of actual functionality you need) and files will be short.
What is the correlation between well engineered software and having many files?
I agree with everything you said, but this one I don't know about, especially with pretty much any editor with some navigation features. Possibly I just have no idea what "big" project means.[/quote]
It's not so much that well-engineered software will have many files. It's perfectly possible to have a small, well-engineered project with just a few files.
It's more that the number of files scales with complexity rather than the length of the files.
If you look at a project and it's 200,000 LoC and there are on 50 files.... that's a worry. (Side note: from a productivity pov, this is especially worrying in a language like C++ where file length can impact build time).
Even if the IDE allows for easy navigation within the file, it still means that you have almost certainly violated SRP for a module.
If your files are too long that might mean that your file is doing too much varied stuff and should be broken into more fine-grained purpose-build modules.
What is "too long"? How many lines is too long? This is a relative term and can vary depending on the overall perception of the project and coding style (... both of this are unstructured yardsticks). Also is a compact (or non-compact) coding style taken into account?
I prefer to use actions, relationships and manageability in determining when I split files (or not), i think that way you build a structure and you know what a file (class) is doing rather than using an unstructured yardstick of whether a file is too big or not
Of course this allows for subdividing actions thus creating new files to enhance manageability. A caveat here is the manageability factor may depend on experience - but that's fine
General stats on my project:
Engine -- 90565 LOC / 364 Files / ~249 lines per file
Tool -- 13757 LOC / 64 files / ~212 lines per file
External dependencies -- 671087 LOC / 3058 files / ~220 lines per file
But yeah, there's some files with 10 LOC and some with 3000 LOC...
I'm actually surprised to see that across all my external dependencies, my tool codebase, and my engine codebase, ~200-250 LOC per file seems to be a fairly consistent average value!
I'm in a situation pretty much like servant of the lord, I have about 13 years worth of home stuff. Obviously quite a few files and classes. As said, when you work in a team with other programmers, and bring in lots of third party libraries it's a different ballgame, and things multiply much more than a single programmer can produce .. when you work on a big project, the priorities can change, and things like optimizing build / link times can become important. :o
The most important thing for me personally as time goes on has been to concentrate on code reusability. 90% of the stuff I write is libraries. That way I can pull in whatever I need for a particular project. So I have libraries for common, debugging, files, maths, primitives, meshes, animation, surfaces (images, loading saving, resizing, blitting, blending etc etc), gui, networking, template libraries, third party stuff etc etc. Most of the stuff you need to write will come up again, so why not make the effort to make it reusable and save yourself the trouble next time. :)
Interestingly, I've always striven as I go on to do more with less code. Templates are cool. I'm always finding better / smaller ways of addressing the same problems (or realising how stupid I was first time round lol :D ). I would hope with less code to achieve the same thing, there is less potential for bugs.
Of course when you are working at a company, they own the code, and when you change jobs, you lose what you have written. So there may be less reason to build up such libraries and more use of third party stuff. There also tends to be more bodgy code written for milestones, deadlines etc *cough*.
Author
Interesting. 800+ files is a lot. It sounds like I'm doing a good job at least. All those morning sitting in my chair drinking pots of coffee contemplating how the little peaces fit together, has lead me to lots of short files. I though they were bigger but I just checked and the TGA loaded is by the biggest at 689 lines. It still seams big to me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
