3

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?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Wayne Werner
  • 49,299
  • 29
  • 200
  • 290
  • What do you have against characters which are 1/4" wide? – Pete Kirkham Jun 30 '10 at 17:10
  • Why is this specific to Visual Basic? Perhaps VB has some constructs that look really ugly if you try to wrap them, but if that isn't the case, then this seems language agnostic to me. – A. Levy Jun 30 '10 at 17:11
  • Well, in a lot of languages /most/ constructs are pretty short (or they look nice when wrapped). In VB (especially when doing event handling) you'll have something like `Protected Sub myLongMethodName(ByVal sender as System.Object, ByVal e as System.EventArgs) Handles SomeObject.SomeEvent` - quite a few characters past 80. I haven't encountered anything nearly that verbose even in Java. – Wayne Werner Jun 30 '10 at 17:29
  • VB does have line breaking, so at least you aren't compelled to make that a one liner. – StingyJack Jun 30 '10 at 17:40
  • 1
    The trouble in Java is the number of nested indent levels that Java code often has. The same problem exists in VB, C#, Java, Pascal, etc. A nice thing about sticking to 80 character limits is that it reminds you that once you have seven levels of indentation in your function, you should probably be breaking your function up into reasonable sub-functions. – Warren P Jun 30 '10 at 17:40
  • That was more or less the question, StingyJack - if breaking that (and others) up was considered A Good Thing™. Warren, that's an excellent point (though I don't know if I've made it that far in any of my Java code!) – Wayne Werner Jun 30 '10 at 18:09
  • In many languages, a statements is terminated via semicolon or other delimiter. In VB, a newline terminates a statement UNLESS the immediate preceding two characters are a blank and an underscore. Multi-line statements tend to be uglier in VB than in other languages. – supercat Jun 30 '10 at 18:09

8 Answers8

9

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
  • 29,056
  • 6
  • 39
  • 56
  • 2
    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 Jun 30 '10 at 17:39
  • 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 Jul 01 '10 at 03:28
  • 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 Jul 01 '10 at 15:20
4

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
  • 478
  • 3
  • 12
1

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

Jason
  • 51,583
  • 38
  • 133
  • 185
1

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
  • 19,041
  • 10
  • 63
  • 122
1

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
  • 1,175
  • 1
  • 9
  • 14
1

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
  • 17,253
  • 17
  • 63
  • 98
0

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.

Catharsis
  • 466
  • 3
  • 9
  • 20
0

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
  • 12,887
  • 8
  • 80
  • 109