Lines of code is mostly pointless, I've had files with 5k lines of code and there was no reason to split up the file. Then again, I'm mostly using languages that are very structured, I would not do that with PHP or JS;

Kotlin, Java, Dart, ... 5k lines in file is not that hard to maintain inside a 450k LOC project.

There is no right answer here. It's part preference, part performance. You could have 1000 very small files with < 300 lines or 100 larger files with 3000 lines. No difference, except in performance. Opening and merging 1000 files in real-time in a language like PHP is going to be slower than opening and merging 100 files.

A good IDE can mitigate this problem altogether. For example, in my IDE, I can see the methods in a separate pane, so navigating to the method I want is a breeze. Also, a decent IDE can let you jump to the source in some fashion by highlighting the method you want and pressing a key.

I think what matters more is what those files contain, now how many lines are in them.

One question, a million answers. Personally, I do not care about LoC. When I am in a job interview, my (maybe) future boss might be interested in LoC I have written in my biggest projects. But I will never take a look at the ln# and say "Oh boy, 300 lines, time to think about splitting up this monstrosity with some smart pattern." Some concerns need 2k+ lines. Some concerns are done and fine with 5 LoC.

The important part is that you do a separation of concerns in a way which is clever, easy to grasp (for other team members or people who will have to maintain your code when you have left over 10 years ago) and fits well with the type of program environment you use (including language, compiler/interpreter, optimization,...). Also, inside each and every file, use a good structure or pattern to achive a uniform, easy to read style, which boosts overview.

I like them very small. 100~150 lines for me. Anything above that starts to slow me down.

This is a soft limit though. There are exceptions, of course, since the most important thing is separating concerns, not truncating the file. But more often than not, big files are a symptom of clustered concerns.

I think the right number if the lines you need, but force to have more files than lines, i prefer to cut and separate functionalities and make every file make sense for himself. I think a good number maybe between 200 or 300 lines, and every method don't need to have more than 30-40 lines? If you think about how to organize your code, this can be made easy :)

depends ... if it's about maintainability in general less is better and the cyclomatic complexity should not be that high .... but most interpreter don't optimize in that way and are just reading something from a file and cache it for N-iterations.

for example doing this in PHP5 (not as extension) PSR-4 compatible is, at least performance wise, just stupid. doing this in smalltalk or java which in the end compiles, inlines and optimizes the shit out of it is smart.

I'm more a 1 to 10 lines per method person and like to use the flyweight pattern, but if you think about controllers and routes, which are basically facade patterns, the question of semantic grouping and SOC (abstraction into service layers) is more important too me than the ideal length of characters in File....

as always imho this is more about taste ...

1