As we diligently write our code, files can get big. This means that scrolling can become increasingly tedious, especially if you want to quickly hop through code many lines apart.
An obvious way to mitigate this problem might be code folding. Yes, this feature has been around forever, but it also has a relatively new sidekick: the minimap.
Code folding can be useful when you quickly want to hide code you’re not interested in out of the way to focus on relevant code. And the minimap can help when your file gets too large, because you can recognize certain parts of your code by shape and quickly scroll to where you need.
However, I believe that in the long run these two features are hurting the quality of your code.
This feature allows you to collapse certain blocks of code, depending on the language. I see two main problems with hiding code:
If you can afford to hide code in a file you’re working on, that code is not that important to the file and should probably be somewhere else.
If you don’t look at the code, you might miss out on some cool ideas for improvement. Out of sight, out of mind.
This feature utilizes the fact that humans are great at recognizing shapes, but it also means that your code got so huge that you need an actual map to navigate through it! Why not have more files instead and quickly navigate through them using fuzzy search?
Why am I ranting about this? Because developers usually work in teams and I can really tell when someone was using code folding and minimaps—usually when I encounter a file that’s 600+ lines long. Sure, I can suck it up and use those features as well, but what if my Vim doesn’t support them? What if I can’t find an adequate plugin for that specific language? What if I want to read code from GitHub, not my text editor? Code architecture shouldn’t rely on these features.
An important indicator of codebase health is how quickly a new developer can pick it up, keep this in mind while designing your code.
Read next → The Nuances of React Transition Group