When evaluating things like how 'well engineered' a project is, then one really needs to take stats like LOC and file count in context. Ease of use and understanding tends to be a better sign of just how well engineered a project is, and often a huge part of the overall engineering that people overlook isn't in the code and how the code itself works, but rather at the project management level and documentation.

You can have code that is blazing fast, super compact, and that was produced in record breaking time for the level of functionality and lack of bugs. But often 'how good' your code is won't be judged by you at the time, but rather by the poor sap who comes onto the project after you're gone on to bigger and better things, or were hit by a bus. Or even judged by yourself, years later, as you stare at your screen holding your rapidly cooling coffee while asking yourself "WTF was I thinking here? Why... Why did anyone ever think this was a remotely good idea?"

"WTF was I thinking here? Why... Why did anyone ever think this was a remotely good idea?"

I've already done this looking at code I wrote 4+ years ago.

When evaluating things like how 'well engineered' a project is, then one really needs to take stats like LOC and file count in context. Ease of use and understanding tends to be a better sign of just how well engineered a project is, and often a huge part of the overall engineering that people overlook isn't in the code and how the code itself works, but rather at the project management level and documentation.

This is one thing I have been trying to get down. My project layout is pretty simple. I was thinking about separating source files. This way I wouldn't have to scroll through a giant tree/list when I'm currently working on a small selection. I wish I had a resource for that. Some guide of some sort that explains project layout and structuring like directory naming and similar things for large scale projects. Provide some good examples maybe, of common pitfalls the industry faces or perhaps some more personal examples from the author.

As my project growing, I realize I will need a better approach for structuring. Its hard to see into the feature to exactly what I will need or want. So I think focusing on whats important to me now would be best. Organizing common libraries and system/platform specific code. Now that I've been thinking about it, this doesn't need to be directory related. I can have only one source directory, but in visual studio or I can have an entire "virtual" directory structure. I'm not sure what would be best.

i used to split programs into modules/libraries based on functionality, with a couple dozen source files being typical for a game, and games typically in the range of 30K, to 50K to 100K lines of code.

in my current project Caveman, i just have 6 source files:

generic gui components: 357 lines of code

custom fonts: 211 lines

audio: 1117 lines

in-house gamedev library: 7275 lines

game specific code: 144121 lines

things are still split into modules / libraries based on function, but now almost all generic modules are in the gamedev library module, and all game specific modules are in the single game specific source file. modules simply appear one after another in a single file, instead of in separate files. this saves a lot of time jumping around between different files. only the game specific code changes, so i really only work with one file most of the time.

also, this is not a "for fun" project, so i have zero time for playing around with software architecture, which tends to lead to lots of files, etc. the sad fact is that refactoring for refactoring's sake accomplishes nothing. it gets you no closer to "gone gold". if its not "for fun", "gone gold" is what really matters. what i do now is: if i notice an API needs to be improved, i write a new version, and use it going forward, but do not re-factor legacy code unless i revisit it for some reason. this gives me the flexibility to make changes to existing code using the old api, or the new api if needed, and the power / ease of use of the new API for new code.

back in the day, my software render alone was a dozen or more files.

compile times for large files are not an issue for me. 144K lines of code in 4 seconds. MSVC++ seems to spend more time opening source files than anything else.

but link times for a release build are on the order of two minutes.

note: this is non-OO c++ code, so there's nothing like one file per class or anything like that.

Refactoring "for the sake of refactoring" isn't a great thing, but that is very much different from taking time to step back and review how you're going about things, and that very much can advance you farther along toward your end goals even if you spend time 'not advancing' while you hammer things out.

Spending time digging the hole of clunky and hard to work with code even deeper might keep you 'moving forward', but charging headlong into a dense jungle rather than taking time to sit down and find/build tools will "let you keep moving forward" too... You'll just make a lot more headway in the long run if you had a machete with you.

The only time I refactor, or have been refactoring has been when I want to clean the code up or I to add features. I tend to snap things in quite a lot to get working, then come back and fix it later where it needs it. For example, I just finished writing a nice GUI. The rendering makes use of a Theme class. Each widget(component) in the GUI will use this theme class to draw it's self using theme parts: colors, images, sounds, etc. I just slapped it together to get it working. Later I wanted to change it to allow a more data-driven approach with out thinking about it, and I broke it. There were reasons why that happened, but now I have to go back and rewrite a bit of my framework. Effectively refactoring the code. Its okay though, because it needed done and it allows for better advancements. Eventually, all this code will become the "new and improved" engine my game runs on. I'll also reuse the same engine for other projects so...