When I decided to switch from Eclipse to vim, I remember being apprehensive of the clumsiness I would have to experience while facing vim's supposedly steep learning curve. I would have to lose lots of handy features, try to regain some of them plugin by plugin and survive with vim's at the time somewhat alien interface until I got comfortable with it.
One thing that helped me regain a lot of the speed I formerly had was a very low-level feature: the ability to split windows. While on Eclipse, I had not
even considered doing it because my window was filled with very "handy" panes that would show me a file tree, methods in the current file and so on. Once on vim, I found plugins to have those kind of panes back, but I did not seek to enable them by default because by the time I found those plugins I had realized a very important thing for my new workflow, something even more important than the fact that I did not really need a menu:
Being able to see several files at a time is way, way, way more important than having any of those panes.
It is the same kind of feeling you get when you start working with an additional monitor.
When I work on a piece of code, I typically have my vim window split in 4 or more vim "windows": the separation of concerns makes it so that you will often work with a service, a controller, corresponding tests, a template, some models and will need to quickly switch back and forth between them. When using Eclipse, I would often Ctrl+click keywords and navigate through the code, each click leaving me with one new tab I did not really care about, and then I would cleanup tabs I did not need. With vim, those tabs do not show up. They are still in the so-called buffer list, but that one is not visible by default.
I found that a bit stupid at first, but then it clicked: just split your window several times, and display files you really care about. Instead of remembering their name and looking for them in a long list of tabs only a few of which you actually care about, just look at your screen and recognize the file by its contents. The switch is instant. And that is if you need to switch, because sometimes, all you need is to read something in the file, not edit it. And if the file you want is not displayed, either split even more or consider replacing one of the windows you already have with the buffer that has the file you need. That file switch is a very low level action, and it is important to get right because you have to do it all the time.
And that's when I started paying a lot more attention to the length of the lines in my code. Nowadays, widescreens are the norm, and it seems to be an argument for people who disregard any limit in line length. But it is not about being able to edit files on an 80-chars wide terminal, like they often claim it is: it is about being able to see several files side by side.
And even if you do not see the benefit of split windows, ask yourself why this blog post does not span all your screen, or why newspapers use columns.
Spoiler alert, it is, among other reasons, because it is far more efficient to scan that than a long line of text. Convinced? Then start writing your code for human beings, start using split windows and tell your fellow developer about that.
Top comments (10)
I do the same, but using Intellij I can have the best of both worlds: multiple pages either side by side within the same window, or across my two monitors. I have a preference for the second option, since it combines mutiple pages with lots of screen realestate for each page.
With regard to keeping pestering people about it, though I know the post and title might at partly be in jest, do be aware that software development is typically a team sport, and trying to foirst person idiosyncracies on other people is a sure-fire way to get you on TDWTF.
What I'm saying, especially with the last paragraph, is that it's not an idiosyncrasy. It's the way human layout text, and programmers should not make an exception with code IMO. Code is still text other humans will need to read, don't make it hard for them.
True enough, but that applies equally so to having code statement arbitrarily cut into different lines based on a screen width far smaller than what you (i.e. any other developer than you) are using.
First rule to making a maintainable code-base: make it as easy as possible for the next developer. And that is far more likely to not be you.
No it does not apply equally, see the video I linked to: the width of the text is not based on the width of the screen (I only work on widescreen by the way), it's also not based on the width of a split window, but it's based on the width humans are comfortable reading. I mean look at this blog post: does it spawn all the width of your screen? Why do you think the vast majority of websites does just that?
The point I'm trying to make in this article is that getting a widescreen is that the screen real estate you are getting should be put to good use by using split windows instead of just making your lines longer. Maybe you will see the point when you buy a 4K screen and your files get even wider.
I have two of those here, and code isn't (and should never be) fullpage text.
I do agree with you about split screens being useful. It's only the absolute and rather low 120 character limit I take issue with.
That limit often depends on the language: I use php, and the recommended limits are 80 and 120 (yes, there are two). In python, it's more like 72, and apparently, in Java, that would be 80. Not sure what your favorite language is, but maybe it culturally has a higher limit? Anyway, I find 120 very comfortable, but when I cross that limit, I try to make the offending block under 80.
My language of choice is Java. The 80 character limit that you mention is most likely either part of an old Java style guide (the most recent Oracle Java guidelines are from 1999), or a result of inertia (Google apparently moved to 100 characters as a compromise to those still preferring 80).
Java has a well-deserved reputation for verbosity (which I don't see as a negative), which means that while most of the lines of code I come across tend to be 100-120 character wide, a fair share are 120-150.
Might be ok indeed for Java, I did not practice a lot but I still remember "System.out.println" vs "echo", so it could indeed make sense in that language.
That's a very mild example. For some laughs and groans, try googling "java long class names" :-).
lol even german does not produce such long words