I'm a big proponent for just slamming code into few big files. There seems to be a fear of complexity that causes people to pack behaviour into many little files, but all it does is hide the complexity not reduce it. In fact it will increase it because now you have more moving parts that need to communicate with each other. And especially gameplay code often consists of tightly interlocking systems.
You can't make the complexity go away, some parts of a game just are that complex.
@accidentlyAnton if it's all just functions ... sure
if it's multiple different classes and systems ...... eeeeeeeeehhhhhhh
2000 lines of data is also eehhh - save that somewhere else
why would you want all of that open all the time when you are not working on that part
@YinYinFalcon Yes, if it's systems that can be split in sensible ways, please do! IMHO sometimes people are too eager with that.
Yeah, data should go into its own files, in the LLB Angle Tool example I guess it was mostly lazyness to keep that there, but also there was no cost to having it open. It's off-screen anyway, and if I need to go to a specific function I search (Ctrl+F) for it, I'm not gonna scroll around.
What I'm trying to say is, that to me, big files are not inherently evil.
@accidentlyAnton @YinYinFalcon I'm probably one to be somewhat on the eager side to split into different files. I justify that by the long lasting trauma of having to work on a ~40000 lines of code file with mixed logic (no there is no typos =| ).
I'm grateful to land on a neatly organized project now, so I try to leave the same for the people after me. In my mind it's easier to merge files if needed than splitting them up.
@glomzubuk @YinYinFalcon Okay, that sounds too much, even to me. I've also once dealt with xml configuration files in that order of magnitude and it's no fun (if only because the average text editor will crap itself).
Merging being easier than splitting is an interesting point, after some consideration, I think I agree with that.