views:

169

answers:

8

In times past, most people coded on a terminal that was 80 characters wide. In many languages this has become, if not holy then close to it.

But now many people have 20"+ monitors (or dual monitors), so screen real estate isn't as prime as it once was.

So my question is this: in Visual Basic code, should code be limited to 80 characters, should there be no limit, or is it really a subjective thing, dependent on where you work and your own preferences?

+1  A: 

Do what is most comfortable and works best for you. This is pretty much a universal truth for everything.

Jason
+1  A: 

Subjective, but within some constraints (for example, if everyone is issued a monitor with size X). We use 110 characters, and it works for us even though some of us use widescreen monitors rotated to portrait.

StingyJack
+1  A: 

I know a number of people who are remarkably fastidious about 80 character lines. As an arbitrary standard it's not bad, but if nobody is nagging you make it whatever length you feel comfortable with.

Jeremy Kemball
+9  A: 

I think it is subjective, but not completely. Limiting code to 80 characters will make it more readable. This is the reason that newspapers have their articles in columns. It is easier to read text if it doesn't get much longer than 70 characters or so. I believe that people have done usability studies on this, but I don't have the references to back that up.

So, again, it is subjective, and situation-dependent, but longer lines are harder to read. So I try to stay within 80 characters even though I don't have to do so.

A. Levy
It is beneficial in those cases where you want to print to a 8.5" wide piece of paper and use a readable font size, and avoid clipping, truncation, or wrapping.
Warren P
I disagree. Although it is true for normal text, code read a lot different. Very often when I have to break lines to match 80 character limit I make the code LESS readable. Now of course there are valid arguments on the other side too, if lines are too long maybe there is a problem in the structure of the code (too many arguments etc). However I tend to be verbose in the naming of variables and functions so the 80 character limit becomes often very limitative. As for the printing argument I have not printed code for many years, always thought it was a waist of paper.
Newtopian
I find that code seems more readable to me when you have small scopes and short variable names within those scopes. You don't need a long descriptive name if you defined the variable 10 lines up. Since names are short, you don't have to break as many lines, and this also decreases (slightly) the time it takes to mentally parse the code. That said, I think I can agree with you on this Newtopian. If you use 80 chars as a hard limit, you can make your code less readable because you would break a really readable 86 character line into a clumsy multi-line representation.
A. Levy
+5  A: 

Humans read and comprehend fastest, when there are 40-70 characters per line of prose (approx. 10 words per line). I think something similar will apply to code.

tathagata
+1  A: 

Approximate 80 characters is what I'd recommend. What I do with the extra monitor realistate is have 2 code files side by side. And the 2nd screen gets all the toolbars, property windows, and a 3rd code or interface layout window.

jamone
A: 

I'm going to go against the grain here, but I say don't limit yourself. If you are abbreviating class/function/variable names for the sake of saving space, you are just taking your code one more step away from being quickly grok'd. I think everyone should hop on the widescreen bandwagon anyway.

Austin Kelley Way
A: 

A problem is sometimes people may code in a window that isn't full screen, and then have to scroll, or the code wraps automatically.

Having to scroll left and right to read code is horrible.

I've had the issue with comments in code.. either limiting them in number of char wide.. or putting them in a different file!

barlop