Journal tomhudson's Journal: Source code density and increasing screen resolution 18

In the beginning was the ...
...skip that ...
we won't go into patch boards and panel switches, or punch card and paper tape readers.
Instead, we'll start with the early micros people played around with when writing code.

In the beginning was a 32 column by 16 row display of text on a TV screen.
Total characters on-screen at one time: 512.
Nobody really misses those days.

Then there was a jump to 80 column by 24/25 row displays.
With true uppercase and lowercase letters, instead of reverse video for lowercase.
Wow!
Total characters on-screen at one time: 2,000.
Monitor sizes in those days were 12" (green or amber display).
Our up to 14" (cga/ega).
Quite a jump.
Nobody really misses those days either.

Then came higher text displays on 15" vga screens.
... or 14" if you didn't mind the eyestrain.
Up to 80x60.
Total characters on-screen at one time: 4,800
Nobody used them, because the fonts were all squished up.
Or, you could remap the vga registers and font tables.
This gave you up to 120x60, (7,200 characters), but that was just sick.
You'd go blind trying to use it with the lousy dot-pitch crt screens.
So nobody missed that, because nobody used it except to prove it could be done.

Today, we have hidef screens capable of 240 characters across by 75.
Using the the same cell size (8x16) as the standard vga text screen we get ...
... .wait for it ...
..18,000 characters total display!
9 vga text screens at once.
But razor-sharp.

So, what do we do with this capability?
Do we change our coding habits to use any of this new-found capability?
No. We insist on scrunching our code in the left-hand column.
We shrink tabs from 8 to 4 or even 2 spaces.
We use carriage returns like crazy.
As the Brits would put it, we "can't be arsed" to try something different.

Reasons:
1. Inertia, pure and simple.
2. We believe that putting multiple statements on one line must make code harder to read and to maintain.
3. Where would we put the comments if we can't attribute them specifically to one statement on its' own line?

Inertia is not an excuse, so I'll ignore that one.

I've always been a bit partial to collapsing single-line if and for blocks onto one line.
It looked odd to me to, at first.
You'd be surprised at how quickly you get used to it, and appreciate the conciseness.

Say you're writing half a dozen different overloaded constructors.
All differ in their parameters, and then call other constructors,
Writing each entirely on one line is actually easier to scan after a while.
Yyou can quickly see which cases you missed, etc.
So I tried it, and I found I liked it.
Cleaner, more concise code.
It helps that I have the editor set to 184 characters per line.
It also helps to use 8-space (real) tabs to set the constructor off from its' body ...

Yes, I can hear the shrieks of horror.
But having tried it for a couple of weeks, it's like dual-screen coding
It's painful to go back to "the old way".
Contrary to expectations, it's not that "visually jumbled".
It just takes your eyes and brain a few days to adapt, and then it's "normal".
It also makes cut-n-paste-modify errors really stick out.
This couldn't be done on those older displays ... and I don't miss them.

So that just leaves #3 - comments.
I've noticed over the years that the more I code, the more commenting is wasted.
Time spent on commenting code that is a work in progress is non-productive.
You know it's true.
90% of the code you write is going to be changed.
Either refactored, replaced, or discarded before you're satisfied.
... and if it isn't, you're probably not doing it right, or someone is rushing you to produce something that "just works".
They don't care how ugly and unmaintainable and error-prone it's going to be in the future.
They won't be getting the blame, since they didn't write it.
So commenting that 90% is a waste.
Worse, the comments sometimes won't align with the final code ...
... and who is allowed the time to fix that in todays' work environment?

Second, we all say that source code should be as self-documenting as possible.
You know, descriptive class, method, function, variable, macro and file names.
How often have we not changed a symbolic name after the object it refers to has changed its' purpose?
We don't want to "break" the code?
So we have code that needs a comment to explain that the function or class or variable isn't really what its' name implies.
... but we don't put that comment in every instance, so ... "Bad Things(TM)" happen.
The cure is to pick good names ...
... but most people won't spend 5 minutes with a thesaurus or a list of synonyms.
Getting the "juste et bon mot" - the fair and proper word or term - doesn't "look" like productive work to your boss.

It's just a matter of getting out of the "green screen pothole". mindset we've been in for several decades, and which most this post has imitated. Source code is supposed to communicate meaning - both to the compiler and to the people who use it. Why are we still insisting on writing code like a grade-school primer? "See Spot Run newline Run Spot Run! newline See Sally play with Spot! newline". We have the hardware to do better.

I believe "classes if necessary, but not necessarily classes", just as I also believe in "comments if necessary, but not necessarily comments." Obviously, the fewer that are absolutely needed, the cleaner the code.

After a few weeks of working with code that's completely commentless except for the file header, and with much of it consisting of multiple statements on single lines, I not only got used to it - I find that it's quicker to edit, since there's a lot less scrolling.

As an example, the same file that takes up 126 lines (of which 10 are header comments, and about 1/3 of the rest are empty lines to separate function pairs), expands to almost 2,000 lines when laid out conventionally and with everything commented "nice and proper".

The "nice and proper" version is a real PITA to work with, so I ended up making a second copy and removing the comments and "proper formatting" on my working copy. 126 lines, in this day of high resolution wide screens, works for me.

Now, before criticizing too much, why not just give it a try? I've heard SO many complaints about how wide-screens ("short-screens") waste so much space, but that's in large part due to our anachronistic style of writing code. Fire up your favourite IDE on a hi-def widescreen, and give it a few days. It just might grow on you.