4 ms·
I respectfully disagree. If they are separated into thoughtful modules, then it would be much easier to parse by simply looking at the file and folder names and
by DSMan195276 11y ago
I respectfully disagree. If they are separated into thoughtful modules, then it would be much easier to parse by simply looking at the file and folder names and going from there. This will especially be true when this expands past it's current state, and it becomes impossible (Or more impossible) to see what uses what.
IMO, 20,000 is already way to much, but when that reaches 100,000 even just editing it will be a chore, let alone using it. It will simply be unmaintainable and unusable. I say this having worked on code bases which have reached that point and attempted to deal with the issues it creates. There's a reason every decently sized code base out there uses multiple files and a hierarchy. It's a natural way to create modular code, and modular code is simply better code.
- CamperBob2 11y agoIt depends on the editor, I think. It's criminal that so many editors still can't do what BRIEF did 20+ years ago, and give you a quick and easy way to surf through all C/C++ functions in the current translation unit. (e.g., http://i.imgur.com/dmlCCpH.png http://i.imgur.com/dmlCCpH.png ). That's why I still use a buggy BRIEF clone instead of a modern IDE. If I were forced to use someone else's idea of a code browser that was architected around files rather than subroutines, I'd probably be more inclined to agree with you. The idea that the most appropriate way to organize source code happens to correspond to something that a (likely-long-dead) OS implementer chose to call a "file" is a notion that doesn't get challenged often enough.
- ktRolster 11y agoEclipse does that.
- CamperBob2 11y agoYeah, there are plenty of editors that do, but none that I'd want to use on a day-to-day basis.