Comment by klibertp
4 years ago
This really depends heavily on how you use your editor, on its specific features. For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file, and due to a stack of jumps that you can pop, there is usually no need to know or care in which file you are currently, or were previously. Similarly, you mention "large number of files you have open in your editor" as if that was a problem of any kind. For me, it isn't - I have 60+ files open frequently, but I have quite a few ways of searching for/jumping to a specific file, buffer, or content that I want to see, and I never need to cycle through open files or tabs. Most of the time I don't have to care if the file is open - there's literaly no difference in the method(s) of getting to a file because of its state (open or not).
The differences between my and your environments mean that our preferred workflows differ, too, because what can be problematic for you can be easy for me, and vice versa.
That being said, I also don't advocate "splitting everything into super small files". Splitting a file that is less than a "page or two" (I see 61 lines of code on one page, so less than 120 loc) is a mistake and should be done only in special circumstances, while files that grew larger than 500 loc should be refactored if it makes sense. Files over 1k loc have to be split. That's the policy we use at work, and I think it results in a pretty nice and easy to navigate code bases.
Back to the editors, though: as long as the codebase uses a convention - any convention - consistently, you can make it nice to work with, by altering your environment to match the convention. This is where the more configurable and easier to script editors win big time - if there's something in the codebase you don't like, and can't change, you can script it out of sight and out of mind easily. Coming from such an editor, I personally don't have a strong opinion on how the codebase should be structured (which includes the lenghts of files) - I do have some preferences, but I'm not very attached to them. That's just to signal that I'm not the one of people "fascinated" with splitting files for the sake of it :)
> For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file
If your convention involves using the same name throughout different files (e.g. every component has a `styles` object), this becomes cumbersome to do. (Arguably, that's a problem with the convention, but sometimes you don't have control over this...)
Other than that, I mostly agree with you and fully admit that it's a matter of preference and highly dependent on your workflow; I was just trying to point out that a single file is generally easier to navigate with an out-of-the-box experience in most editors. I also agree with your stance on when to split files, with a small caveat: even when splitting something into multiple files, I still tend to group them by their high-level function as opposed to by "type". In other words, I would rather split a helper component into its own file with its own styling in the same file, rather than split all of the styling into its own file. (Of course, sometimes you really do have 800 lines of styles, in which case they probably need to be in their own file regardless.)
> That being said, I also don't advocate "splitting everything into super small files".
That's great! :) I see this too often in frontend web development, though: people will go out of their way to keep their files as small as possible to an irrational degree—almost as if they are trying to ensure that you can view every file in its entirety without scrolling.