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.

A few thouthand lines, give or take a few tens of thouthand lines generated by entity Framework ><

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...

Never refactoring anything and sticking to your first version of all your code is "ok" (for very, very limited values of "ok") as long as you're the only person who will ever touch your software.

As soon as another person needs to interact with your code, organization and cleanup are essential tasks to maintaining productivity. Deleting the dead code is alarmingly important; someone new may have a hard time knowing the difference between the "wrong" and "right" APIs. Cleaning up code is not just faffing around. Contrary to what some may believe, it's crucial to shipping product.

At some point code outlives its original author(s) and becomes legacy. Maintaining and improving legacy code is another extremely important aspect of team-based development.



[edit] 25,000 files totaling just over 7 million lines of code, for the perversely curious.

25,000 files totaling just over 7 million lines of code, for the perversely curious.

Since you've bootstrapped, iirc, is that 7 million lines all Epoch? :o

Using VS2015 Code Metrics...

I'm up to about 35000 lines of code. There are about 700 source files. Pretty maintainable so far.

The stats for my engine (in C++):

- Hobby project

- 4 years in developement

- 113k lines of code (not counting newlines)

- 1335 source files

- => ~80 LoC per file

- Some additional ~100k lines for tools (editor), genre-specific code (top-down 2d plugins, ...), and so on.

Its comfortable to work with that way, some files tend to become larger, some single ones around 1k LoC, but I usually try to split up classes/files if they become this huge. I find it far easier to work with small files, you have a better overview of everything and find things you are looking for much quicker. Goto Definition/Declaration makes jumping around files virtually free.

As for refactoring, I find it vitally important to have a look at old code, even if it still works in the current version. Unless its something you write one time and then never again, you learn just so much from looking at old code and how to improve it.

For example, I have written 3 different visual "scripting" languages so far. While details vary, some core-concepts stay the same. The first implementation was horrible, since I had no idea what I'm doing. Slightly reworking it from here and there gave me a good idea of some larger-scale changes I would make if I were to write it again. So when I wrote the second one, I applied those ideas, and it turned out much better. Then I ended up reapplying those changes to the first visual language, essentially still finding room for improvements in the process, which in turn lead to more improvements on the second language. Now by the time I've written the third one, I knew exaclty how it should look, and now thi swon't require any refactoring in the near future, as far as I can see. If I'd just said "screw refactoring", I would probably have three horrible implementations of a visual scripting language, while now I have 3 decent ones that are way easier to work with, where the third one took no extra effort whatsoever.

So bottom line, refactoring can be really good if you write similar code over and over again and want to learn how to improve it.