3 ms·
The question should be how can they ever let that file grow that big. What kind of engineers were working on that, like I hate seeing any file more than 300-400
by sajithdilshan 6d ago
The question should be how can they ever let that file grow that big. What kind of engineers were working on that, like I hate seeing any file more than 300-400 lines of code
- dgellow 6d agoIf well organized the number of lines of code in a file is really irrelevant. 300-400 loc is a tiny file in any professional project. Splitting in a large number of file doesn’t magically make things simpler to manage, in fact you fragment the context by doing that. And very likely end up with unnecessary abstractions
- sajithdilshan 6d agoI disagree, that makes it more readable, maintainable and testable. Just because everything is in one file doesn’t mean you’ll be able to build the context, you’d forget what was at the start of the file when you get to the bottom of it if it’s like 3k lines
- dgellow 6d agoWe don’t read a source file as a book, from the first line to the last one. A file is just a set of classes, functions, types, constants, and you generally navigate it by blocks. Splitting multiple functions, classes into multiple files just to match an arbitrary number of lines is bad engineering, prioritizing a dogmatic approach instead of a thoughtful one. File units should have a meaning. And there are quite a lots of situation where keeping more things tied together in the same file is a meaningful thing to do, even if the file is itself large. There is an argument for avoiding extremely large files based on the impact on the resulting artifact, but lots of tiny files (400loc is really short) pretty much always results in duplicated logic and over engineering