5 ms·

I don't get the obsession with file length. What's the benefit of having 100 files with one 50-line function per file, over having a 5000 file with 100 function

I don't get the obsession with file length. What's the benefit of having 100 files with one 50-line function per file, over having a 5000 file with 100 functions? Obviously not counting extreme cases where the file size would break some editors' buffers

montenegrohugo 5y ago
Try debugging a single 10k loc file versus fifty small modules where each takes care of a distinct part of the logic.
- userbinator 5y ago
  As someone who did a bit of enterprise Java, I much prefer the former. Jumping around between lots of tiny files and not being able to see where the actual work happens because it's spread everywhere is a debugging nightmare.
  - vonseel 5y ago
    I think you need a better IDE.
- tedunangst 5y ago
  But what's the difference between file1.c ... file50.c vs cat file*.c > onefile.c?
  - timando 5y ago
    I imagine the 50 files have meaningful names. Just kidding, no-one knows how to name anything.
- jokethrowaway 5y ago
  I'm not too bothered by the single 10k loc file (and I've seen plenty of files with thousands of lines). I would aim at files in the range of 200-300 LOC If you split it, it's crucial that you're splitting the logic in the right way (if the modules are too small, they'll just waste your time) and that you're making sure references can be easily traced (eg. if you have modules with some DI system which prevents references from being recognised, as it happens frequently in certain node.js enterprise applications).
honkycat 5y ago
Ability to structure your code base hierarchically Ability to search through your codebase by file name Ability to hide irrelevant information and expose a higher level API through private functions
- CamperBob2 5y ago
  None of those are necessarily driven by file-level organization, though, except for the one about the file names themselves. My mortgage is paid by a 50 kLoC C program with a single 11000-line function. I'm always blown away by how many so-called "code editors" can't give me a simple list of C functions in the file, the way BRIEF could in 1987. Few things annoy me more than having to trudge through a codebase with hundreds of .c files, inevitably all with 8-character filenames. Any day when I have to break out Eclipse to navigate an unfamiliar project is an official Bad Day At Work.
perlgeek 5y ago
Usually (but not always) a single, huge file points towards missing structure, missing abstractions, missing boundaries that aid with understanding. If it were a huge, single file, with very understandable modularity within that file, likely nobody would've bothered to write a blog post about it :-)
zshrdlu 5y ago
Code could be well-modularized in one single file, of course. But we don't have the tools to write code like that (editors and languages basically).
deergomoo 5y ago
Personally I find it much more difficult to keep n places in one giant file in my head than I do n individual files. We have a few multi-kloc legacy monsters where I work and I quite often completely lose my place when working on them (and, by association, my train of thought), even though they’re actually structured somewhat reasonably.
- niccl 5y ago
  I had this problem until I found an editor that had outlining as it's core design paradigm. Now, with the outline always visible, it's _really_ easy to navigate any length file. Unfortunately, at one point I got so used to navigating with the outline that I ended up making a 1500 line function in C (I was an even worse C programmer then than I am now). Because of the outline, I could read and follow it easily, but anyone with a different editor was royally screwed :-( If you're interested, the editor is LEO (http://leoeditor.com/ http://leoeditor.com/) it's been mentioned on HN a few times
chakkepolja 5y ago
* Editor support for perfect semantic navigation may not be taken granted * Compiler support for function-level incremental may not be taken granted * Editor shows a nice file tree (although you can do that with symbols too) * Working with git is easier * Reading code on site like GitHub is easier
heavenlyblue 5y ago
I find IDEs work better with multiple files (i.e. navigation around if you want to have several windows open at the same time), but agree that’s not so well defined.
rodgerd 5y ago
At one point - and perhaps still today - Java would refuse to JIT class files with more than a couple of thousand lines in them, falling back to interpreted mode. So in that case, you really, really wouldn't want the 5,000 line file.
deleted 5y ago
[deleted]
enneff 5y ago
I think the problem in this case was that the entire file was the script that ran top to bottom. It’s not so much that the file was big, but that the function was huge and impossible to reason about. I agree that obsessing over file length is it’s own kind of anti pattern. I have had colleagues who insist on putting every little thing in a different file and that is its own special kind of hell.
magpi3 5y ago
Eventually a single file won't scale. Maybe not in the lifetime of your project, but you never know. If a day comes and you have a 500,000+ line file that must be split into separate files, that could be a nightmare. Why not just follow best practices from the beginning and separate your programming logic into different logical/related units? Similarly having the discipline to separate your programming logic into different files will force you to think about the architecture(or lack thereof) of your program. This is a good thing. The Java "one file for one class" model is overkill IMO, but it does force programmers to discipline themselves by thinking in terms of namespaces/classes when they write code, which for beginners at least is not a terrible thing. Obviously version control is another reason. Hard to get work done if everyone is working on the same file. It also will make it easier for someone else to grok your program. When I git clone someone else's large project, I start trying to understand the project by writing down what each folder and file is designed to do before I go any further. I suppose if everything was in one file I would just have to do the same for functions, but what if there were thousands of them? Imagine if a large program like WordPress, Doom, the Linux Kernel etc was a single file? TLDR: For small one person projects, no big deal. Otherwise, it's just a bad/unscalable practice.
benibela 5y ago
It depends on your tooling I just searched for the largest code files on my system and found a 100k file I opened it on the online repo and gitlab did not want to show it at first. When I clicked on show anyways, Firefox broke trying to load the website and I had to restart it. (then I could not post on HN anymore due to the noprocrast setting there) When I opened that file in an IDE, it was shown quickly without any issues. But there is a notable delay when typing, so 100k lines are too much. Other IDEs might already fail with smaller files Although when the IDE has a "search in the open file" and not a "search in all files of the project" feature, one file is much easier to use than multiple files

montenegrohugo 5y ago

Try debugging a single 10k loc file versus fifty small modules where each takes care of a distinct part of the logic.

userbinator 5y ago
As someone who did a bit of enterprise Java, I much prefer the former. Jumping around between lots of tiny files and not being able to see where the actual work happens because it's spread everywhere is a debugging nightmare.
- vonseel 5y ago
  I think you need a better IDE.
tedunangst 5y ago
But what's the difference between file1.c ... file50.c vs cat file*.c > onefile.c?
- timando 5y ago
  I imagine the 50 files have meaningful names. Just kidding, no-one knows how to name anything.
jokethrowaway 5y ago
I'm not too bothered by the single 10k loc file (and I've seen plenty of files with thousands of lines). I would aim at files in the range of 200-300 LOC If you split it, it's crucial that you're splitting the logic in the right way (if the modules are too small, they'll just waste your time) and that you're making sure references can be easily traced (eg. if you have modules with some DI system which prevents references from being recognised, as it happens frequently in certain node.js enterprise applications).

honkycat 5y ago

Ability to structure your code base hierarchically Ability to search through your codebase by file name Ability to hide irrelevant information and expose a higher level API through private functions

CamperBob2 5y ago
None of those are necessarily driven by file-level organization, though, except for the one about the file names themselves. My mortgage is paid by a 50 kLoC C program with a single 11000-line function. I'm always blown away by how many so-called "code editors" can't give me a simple list of C functions in the file, the way BRIEF could in 1987. Few things annoy me more than having to trudge through a codebase with hundreds of .c files, inevitably all with 8-character filenames. Any day when I have to break out Eclipse to navigate an unfamiliar project is an official Bad Day At Work.

perlgeek 5y ago

Usually (but not always) a single, huge file points towards missing structure, missing abstractions, missing boundaries that aid with understanding. If it were a huge, single file, with very understandable modularity within that file, likely nobody would've bothered to write a blog post about it :-)

zshrdlu 5y ago

Code could be well-modularized in one single file, of course. But we don't have the tools to write code like that (editors and languages basically).

deergomoo 5y ago

Personally I find it much more difficult to keep n places in one giant file in my head than I do n individual files. We have a few multi-kloc legacy monsters where I work and I quite often completely lose my place when working on them (and, by association, my train of thought), even though they’re actually structured somewhat reasonably.

niccl 5y ago
I had this problem until I found an editor that had outlining as it's core design paradigm. Now, with the outline always visible, it's _really_ easy to navigate any length file. Unfortunately, at one point I got so used to navigating with the outline that I ended up making a 1500 line function in C (I was an even worse C programmer then than I am now). Because of the outline, I could read and follow it easily, but anyone with a different editor was royally screwed :-( If you're interested, the editor is LEO (http://leoeditor.com/ http://leoeditor.com/) it's been mentioned on HN a few times

chakkepolja 5y ago

* Editor support for perfect semantic navigation may not be taken granted * Compiler support for function-level incremental may not be taken granted * Editor shows a nice file tree (although you can do that with symbols too) * Working with git is easier * Reading code on site like GitHub is easier

heavenlyblue 5y ago

I find IDEs work better with multiple files (i.e. navigation around if you want to have several windows open at the same time), but agree that’s not so well defined.

rodgerd 5y ago

At one point - and perhaps still today - Java would refuse to JIT class files with more than a couple of thousand lines in them, falling back to interpreted mode. So in that case, you really, really wouldn't want the 5,000 line file.

deleted 5y ago

[deleted]

enneff 5y ago

I think the problem in this case was that the entire file was the script that ran top to bottom. It’s not so much that the file was big, but that the function was huge and impossible to reason about. I agree that obsessing over file length is it’s own kind of anti pattern. I have had colleagues who insist on putting every little thing in a different file and that is its own special kind of hell.

magpi3 5y ago

Eventually a single file won't scale. Maybe not in the lifetime of your project, but you never know. If a day comes and you have a 500,000+ line file that must be split into separate files, that could be a nightmare. Why not just follow best practices from the beginning and separate your programming logic into different logical/related units? Similarly having the discipline to separate your programming logic into different files will force you to think about the architecture(or lack thereof) of your program. This is a good thing. The Java "one file for one class" model is overkill IMO, but it does force programmers to discipline themselves by thinking in terms of namespaces/classes when they write code, which for beginners at least is not a terrible thing. Obviously version control is another reason. Hard to get work done if everyone is working on the same file. It also will make it easier for someone else to grok your program. When I git clone someone else's large project, I start trying to understand the project by writing down what each folder and file is designed to do before I go any further. I suppose if everything was in one file I would just have to do the same for functions, but what if there were thousands of them? Imagine if a large program like WordPress, Doom, the Linux Kernel etc was a single file? TLDR: For small one person projects, no big deal. Otherwise, it's just a bad/unscalable practice.

benibela 5y ago

It depends on your tooling I just searched for the largest code files on my system and found a 100k file I opened it on the online repo and gitlab did not want to show it at first. When I clicked on show anyways, Firefox broke trying to load the website and I had to restart it. (then I could not post on HN anymore due to the noprocrast setting there) When I opened that file in an IDE, it was shown quickly without any issues. But there is a notable delay when typing, so 100k lines are too much. Other IDEs might already fail with smaller files Although when the IDE has a "search in the open file" and not a "search in all files of the project" feature, one file is much easier to use than multiple files