Your skill will accomplish
what the force of many cannot
Would you accept that I do not like scrolling and use the syntax highlighter to keep sane? 8)
I like to preach writing code with less than 80 columns, and functions with less than 25 lines. In short, a function should fit on a 1970s terminal screen, or on a 1980s IBM PC clone with a CGA or Hercules video card. Especially our interns have to suffer from my preaching.
It is just a recommendation, after all, to make them write manageable and maintainable functions. Starting with the fact that those 25 lines do not include documentation. In a really well documented program, the documentation should be between half and twice the number of code lines, as a rule of thumb (at least for the way we write code).
And of course I do not recommend writing code on a terminal. I've used two 17 inch CRTs at home until the pandemic started, and I had to work from home. I quickly recognized that the two 1280 x 960 screens are way too small for the semi-modern space-wasting IDE we use at work. It's ok if you work for only a few hours, but it sucks for a full-time job. So I bought two refurbished 24 inch TFTs, providing 1920 x 1024 each, and a monitor stand with two arms. Now my screen estate has grown by about 50 % (and I gained a lot of room on my table below the monitors). That's exactly the same size that I also use at work. In fact, every developer at work has at least two large monitors, 1920 x 960or slightly more, at least 20 inch large.
Now guess how much room I can use for my code. Using a 8x8 pixel font like 40 years ago, I could have 128 lines of 240 characters each. Running our IDE with almost-default settings, I can see 36 lines. Not even a quater of what would be possible using an ugly and tiny font. Closing the omni-present output and result sub-windows that keep popping up when compiling or using advanced editing functions, I may extend that to 58 lines. But as just explained, 36 or so is much more likely, because the IDE chooses to pop up sub-windows for almost any operation. Remember my recommendation to use only 25 lines + 50..200 % of documentation? That's 37 to 75 lines. Horizontally, I see 203 characters per line, a few more if I would disable line numbering, and maybe 250 if I would close all the right-hand side sub-windows. Switching to a simpler editor (Notepad++) does not change that numbers significantly.
We try to restrict our code to 80 characters per line, and I also do so at home for my private projects. But we are relatively relaxed, so if a line grows to 90 or 100 characters, well, that happens sometimes. Heck, even the Linux kernel has relaxed the 80 character limit recently. But writing code were almost every line exceeds 120 characters will cause discussions.
So, to summarize: Get at least two large, high-resolution monitors. Tiny monitors and especially laptop screens really, really suck for writing code. And you want at least two monitors. One for editing, one for documentation, testing, researching.
Another important point is choosing good names for functions, methods, types, variables, constants, parameters, properties, attributes, types, classes, interfaces. Name your functions something like readConfigFile(), printReport(), createDatabase(). Don't call them spaghetti(), lasagne(), and tortellini() just because you can. (I'm not making this one up!) Make the names boringly obvious and self-explaining, so you don't have to think for a millisecond about what that function or variable might do. Have simple rules for names, e.g. lower case function names, upper case variable names, all-upper case constant names, "_t" suffix for types, and so on. Choose whatever you like, preferably choose an existing set of rules.
Syntax highlighting is a nice feature, as is a list of identifiers in the editor. But if you choose a consistent style for writing code, it's just that. A nice feature, not essential. You can work without it.
So, with a little bit of discipline, you can write understandable and maintainable code. A great advantage of Perl is that it comes with POD, so you can write the documentation right before you write the code, and even in the same file. Other languages need external tools like Doxygen and have to hide the documentation in comments. Not quite POD, but it comes close.
And yes, I prefer to write the documentation first. Documenting what a function will do forces me to think how the function will interact with other functions, and how it will be implemented. So, after writing the documentation, I usually automatically have a very good plan for the function.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)