At some point, things get unwieldy. Where do you draw the line and try to break things out?
views:
473answers:
8Rather than worrying about a particular number of lines, just ensure that your code is properly partitioned into areas of concern.
Disclaimer: this answer assumes the the question is about data files. If we're talking about code, then everything changes, of course.
That depends entirely on what you want to do with those files.
If they are meant for logging only or are only handled line-by-line and always in whole, then the only real limit is the file-system limit (or possibly 2GB, if you want to be extra-careful to avoid problems during transport and on different file-systems).
If they represent some structured data that needs effectively random access, then I'd quickly switch to a much more structured approach, such as an embedded database like SQLite or HSQLDB.
I guess this is ENTIRELY subjective and everyone has the own opinions. I hate functions that are larger than about a screen length and then I try to separate things out. But then my colleague hates spaghetti code and if the code is still doing the same unit of work then it should stay in that method. If you are using OO properly and have designed well you shouldn't really have this problem too many times.
BUT here I offer you Java's official guideline...
http://java.sun.com/docs/codeconv/html/CodeConventions.doc2.html
EDIT: For those of you not wanting to follow the link they recommend 2000 lines. Feels right to me.
I would venture out and say that 1 billion is probably too many. I'm currently working on a project where one file has 20,000 lines. But with a modern IDE, it really isn't that hard to work on large files. There's so many tools to find stuff you want, "Go to Definition", "Find", drop down showing method list, that I think there's almost never a reason to go scrolling around a file. When I stop and think about it, I don't think my work would be put off too much if the entire project was in a single file. So long as functions were kept short, and things were coherent. To clarify, If I had to choose between everything being in nice small files, but having a big mess of spagetti code, and having everything coded well in neat little functions, and having everything in a single file, I would choose the single file.
I find that somewhere in the vicinity of 1000 lines of text is where I start getting an itch to split up the code in a source file. It isn't a hard and fast rule, but that's the neighborhood where it happens.
If I'm reading someone else's code, somewhere in the vicinity of 10,000 lines of text is where I start to feel a nearly uncontrollable urge to refactor the code.
Oddly, this does not seem to be language specific, even though different languages operate at different levels of abstration.
It's not really lines of code that get "too many". it's often a development style that makes things "heavy".
For example a very long method body makes it difficult to read. Almost always it means that some things have to be implemented separately maybe even in other tiers.
We have all around 10K lines files and they are really difficult to read. But not because of so many lines. Because the methods contain a crazy amount of logic inside.
Do not put more than one class in a file (except nested classes if you need them). It will automatically limit the file size.
Do not give to a class more logic than its responsibilities assume. It will limit the file size.
If you are with .NET use partial classes to separate the files in several physical pieces. This will also help.
But more important keep your logic simple and transparent.
Personally, I try to keep my class files ~200-300 lines. Too much scrolling is too much annoying. Besides, if it needs to be that long, refactor!