There’s an interesting discussion on SlashDot asking the question of whether we collective programmers should drop the old “80 column” standard that’s still so prevalent and go with some larger number, say 132, or, possibly something even bigger.
With the new widescreen displays, this would almost seem to make perfect sense.
But I think I’d side with the majority of posters that 80 columns is more than enough in most situations. Besides that, there are very good reasons that newspapers and magazines don’t print articles the full width of the page, but instead create columns. The eye just has a hard time sucking up that much stuff .
In the typical programming book I have, I counted an average of about 74 chars per line (proportional, so the number could vary, though not by much). In the paper back books I checked, I see about 54 chars per line. These are single column books.
80 would seem just about right. Long enough to deal with the typical indentation of a programming language, but short enough to keep you from getting lost on the line.
Besides, other than those lines with long tables or strings of text, why would you create a very long line of code? C is pretty notorious for allowing such nonsense with it’s ? operator and inline assignments, but there’s very few that would argue those things make the code more readable. VB has it’s “:” statement separator, but there are very few instances where I’ve seen it put to particularly good use.
Convention generally holds that you want to stick to one statement per line. And typical statements should be far less than 80 chars long.
On a related note, I have a few other questions to throw out
- How many spaces should a tab comprise?
- Is it better to program black on white or white on black?
- Do color coded syntax highlighting editors actually help or just distract?
- Should web pages go columnar when the chars per line exceed some number (for instance, browsing full screen on a widescreen monitor)?
For me, it’s:
- 3 (2 is too few to be visually distinct, and 4+ takes up too much line space),
- White on Black (with a white background, there’s just too much light coming at me. It’s almost blinding to run an editor full screen on a 24″ widescreen with a white background.
- Not much, although I do tend to color comments in a dimmer color than the rest of the code. Everything else I tend to leave as white text, unless it’s a very specific file format. For instance, I have coloring rules for INI files and XML files to highlight the sections, keynames, and element tags.
- Up in the air on this one. On slashdot, maximized, I count about 230 chars per line on my widescreen monitor. They run as a single column and just stretch it out to accommodate the browser. Many news pages simply limit the max width of the page to somewhere around 1024 pixels or so. Here’s a typical MSN page maximized on my system:
That seems like a waste to me.
3 Comments
Oooh… eerie.
3 spaces = 1 tab, check.
80 chars per line, check.
Black text, check.
Color coding, check.
Fixed web pages, agreed.
We’re in 100% agreement; amazing. I thought I was the only goofball on the planet who indents 3 spaces.
Oh, and let me shout out to my good bud, the VB line continuation character! Without it _
we’d spend more time scrolling sideways instead of vertically. Mouse wheels would would _
look 90 degrees different than they do now. Computer programming magazines from the 1990’s _
would look like rolls of paper towels. By 1999 Microsoft would’ve perfected it’s SlimType[tm] _
technology, allowing an unprecedented 1024 characters per line, in only 7.5 physical inches. _
(We narrowly avoided the new screen measurement constant, "TWIPLET".) A laser printer exploded _
at Comdex 2000 when Bill Gates tried to demonstrate Office 2000 SlimText[tm] Edition.
Seems like I have to argue for 3 space tabs everywhere. Glad to hear someone else believes in change the VB defaults!
Yeah, I like the line cont char, but I do wish that VB made better use of intelligent parsing to obviate the need.
For instance, VB is one of the few languages that uses a good token look ahead and back parser so it can parse things like the END IF keyword, as well as understanding the difference between:
IF x THEN
statement
END IF
and
IF x THEN statement
and
IF x THEN statement:END IF
If you’ve ever messed with compiler design, there’s a reason C doesn’t do things like that. It’s hard! And VB does a fantastic job of it.
It just seems to me the compiler ought to be able to tell when I continue a line without a special character for such. Or at least be able to tell under certain conditions.
For that matter, it ought to be able to deal with putting a comment between the SELECT and the first CASE line. Never understood that one.
Heh. After translatng one horrific and complicated error message from a Progress compiler, the developer looks at me and comments, "it seems to me the error message contains enough information for the compiler to just FIX the damned thing instead of stopping the show." We had a good laugh over it, but it got me to thinking… why not?
I *hate* those situations when SQL Server can’t convert a numeric value to a text (or vice versa) without explicitly using a CAST. Or those times when VB squeals about an overflow because I set DEFLNG and an implied subtotal temporarily exceeds a long integer. So what? If it’s an overflow, switch to the next larger data type and DEAL with it whydontcha?
Missing a closing paren? Generate a warning and add a closing parenthesis.
We’ve had spell checkers for decades — but SYNTAX ERROR is still fatal.
If I wanted a compiler as smart as my dog, I’d teach my dog to code. So why can’t compilers be smarter?