What's your maximum line size preference?

[Gianni Mariani]

Do you have a preference on maximum line width for C++ code?

I've seen the craziest debates on this most silly of topic.

I have witnessed engineers spent oodles of time fiddling with line
breaks just to get it right. I find in general a prescriptive rule
makes for markedly less readable code, which unfortunately is a
subjective argument, however, the waste of time modifying code when it
does not need to is not.

I'm interested in knowing what you'all do.

G

 

[Ian Collins]

Do you have a preference on maximum line width for C++ code?

About 80. I find I seldom write lines longer than this and I prefer to
have several files open side by side.

 

[Juha Nieminen]

Do you have a preference on maximum line width for C++ code?

Historically 80 characters has been the recommended maximum because
text terminals were that many character wide, and trying to edit code
lines longer than that would require either scrolling horizontally
(assuming your text editor supported that) or ugly line wraps.

Nowadays 80-character-wide terminals are seldom used for programming
and instead freely-resizeable graphical editors on high-resolution
monitors are used instead, so there's no practical or technical limit.

However, personally I still keep my emacs at 80 characters and avoid
lines longer than that when programming. IMO code lines which are too
long are a bit like text lines which are too long: Hard to read. The
very worst case scenario is when code lines are so long that they won't
fit the width of your monitor and you either need to scroll horizontally
to see the entire line (very bad usability) or the lines are wrapped,
which makes the code even harder to read. I have seen code out there
which badly break this concept and use humongously long lines, which is
a braindead idea.

I think the 80 characters is a good width, although I wouldn't oppose
something slightly larger, eg. 100 characters.

 

[Tim Slattery]

Historically 80 characters has been the recommended maximum because
text terminals were that many character wide,

Just a digression: the 80-character-per-line standard goes all the way
back to Herman Hollerith and his 80-column punch cards, long before
anybody ever thought of text terminals.

 

[Juha Nieminen]

Just a digression: the 80-character-per-line standard goes all the way
back to Herman Hollerith and his 80-column punch cards, long before
anybody ever thought of text terminals.

But interactive programming didn't become viable until text terminals,
which is one of the biggest reasons why 80 characters has always been
the limit.

 

[Erik Wikström]

Do you have a preference on maximum line width for C++ code?

I've seen the craziest debates on this most silly of topic.

I have witnessed engineers spent oodles of time fiddling with line
breaks just to get it right. I find in general a prescriptive rule
makes for markedly less readable code, which unfortunately is a
subjective argument, however, the waste of time modifying code when it
does not need to is not.

I'd say as short as possible without sacrificing the readability of the
code, but keep in mind that a modern monitor is wide. I also think that
different standards can be applied to different kinds of lines, I really
hate things like this:

SomeReturnType SomeClass::SomeMethod(SomeType1 artument1,
SomeType3 argument3,
SomeType4 argument4,
SomeType5 argument5,
SomeType6 argument6,
SomeType7 argument7)
{
// ....
}

Since you (in my experience) seldom have to read or change the arguments
of functions (at least of working on a large code-base with a few years
worth of code) you can just keep them all on one line, which gives a
more uniform formatting of functions and makes it easier to quickly scan
the code.

Also, when you get a few indentation levels deep you generally do not
have many columns left (at least not if you have a tab-size of 4 spaces
or more). I therefore think that it might be useful to count the line-
width from the first non-whitespace character (though I've been unable
to convince my employers this is a good idea).

Having said that, take up a few novel (or some other book) and count how
many characters they put on a line and you get a number somewhere around
80, there might be a good reason for that.

 

[Chris Ahlstrom]

After takin' a swig o' grog, Erik Wikström belched out
this bit o' wisdom:

I'd say as short as possible without sacrificing the readability of the
code, but keep in mind that a modern monitor is wide. I also think that
different standards can be applied to different kinds of lines, I really
hate things like this:

SomeReturnType SomeClass::SomeMethod(SomeType1 artument1,
SomeType3 argument3,
SomeType4 argument4,
SomeType5 argument5,
SomeType6 argument6,
SomeType7 argument7)
{
// ....
}

Since you (in my experience) seldom have to read or change the arguments
of functions (at least of working on a large code-base with a few years
worth of code) you can just keep them all on one line, which gives a
more uniform formatting of functions and makes it easier to quickly scan
the code.

I disagree violently <grin>.

SomeReturnType
SomeClass::SomeMethod
(
SomeType1 artument1, /**< Destination for the stuff. More comment.*/
SomeType3 argument3, /**< blah blah blah */
SomeType4 argument4, /**< blah blah blah */
SomeType5 argument5, /**< blah blah blah */
SomeType6 argument6, /**< blah blah blah */
SomeType7 argument7 /**< blah blah blah */
)
{
// ....
}

I really prefer dragging my eyes /down/ the page, not left to right,
especially wayyyyyy to the right, then back leffffffffffft again,
then down.

Why do you think newspaper columns are so narrow?

I like code I can page down through quickly and grok at a glance.

 

[Ian Collins]

I disagree violently <grin>.

SomeReturnType
SomeClass::SomeMethod
(
SomeType1 artument1, /**< Destination for the stuff. More comment.*/
SomeType3 argument3, /**< blah blah blah */
SomeType4 argument4, /**< blah blah blah */
SomeType5 argument5, /**< blah blah blah */
SomeType6 argument6, /**< blah blah blah */
SomeType7 argument7 /**< blah blah blah */
)
{
// ....
}

I really prefer dragging my eyes /down/ the page, not left to right,
especially wayyyyyy to the right, then back leffffffffffft again,
then down.

Why do you think newspaper columns are so narrow?

I like code I can page down through quickly and grok at a glance.

That gets my vote. Having a child with an eye tracking problem, I've
been though all the exercises and it's surprising how long it takes for
a normal person to locate the start of the next line when scanning long
lines.

I've tried an edit window with 360 character lines and it isn't fun...
My guess is there's only so much text we can keep in short term memory,
so when a line is too long, we forget the beginning of the current line
which makes tracking to the next one hard.

I'm sure there's some papers on this somewhere!

 

[Hendrik Schober]

After takin' a swig o' grog, Erik Wikström belched out
this bit o' wisdom:


I disagree violently <grin>.

SomeReturnType
SomeClass::SomeMethod
(
SomeType1 artument1, /**< Destination for the stuff. More comment.*/
SomeType3 argument3, /**< blah blah blah */
SomeType4 argument4, /**< blah blah blah */
SomeType5 argument5, /**< blah blah blah */
SomeType6 argument6, /**< blah blah blah */
SomeType7 argument7 /**< blah blah blah */
)
{
// ....
}

Just for diversity, I like this:

SomeReturnType SomeClass::SomeMethod( SomeType1 argument1 /**< Destination for the stuff. More comment.*/
, SomeType3 argument3 /**< blah blah blah */
, SomeType4 argument4 /**< blah blah blah */
, SomeType5 argument5 /**< blah blah blah */
, SomeType6 argument6 /**< blah blah blah */
, SomeType7 argument7 /**< blah blah blah */ )
: data1(argument1)
, data3(argument3)
, data4(argument4)
, data5(argument5)
, data6(argument6)
, data7(argument7)
{
// ....
}

(But then I had never had to look at code at a machine which
only has vi. And hopefully I'll never will. :^> )

[...]

Schobi

 

[James Kanze]

But interactive programming didn't become viable until text
terminals, which is one of the biggest reasons why 80
characters has always been the limit.

What does interactive programming (whatever that means) have to
do with it? Fortran restricted line width to 72 characters,
ignoring the last 8 on the card (so that you could put sequence
numbers there---very useful for resorting the code if you
accidentally dropped the deck). The reason most terminals where
80 characters per line is *because* that was the width of the
cards.

 

[James Kanze]

Do you have a preference on maximum line width for C++ code?

I've seen the craziest debates on this most silly of topic.

I have witnessed engineers spent oodles of time fiddling with
line breaks just to get it right. I find in general a
prescriptive rule makes for markedly less readable code, which
unfortunately is a subjective argument, however, the waste of
time modifying code when it does not need to is not.

I'm interested in knowing what you'all do.

It depends somewhat on the context:

-- Fundamental technological constraints (and yes, they are
still relevant today) means 80 characters, no tab characters
(and displays with fixed with fonts) are an absolute
maximum. At least for code which has to be readable over a
more or less long period of time or with different (possibly
unknown today) equipment; I'll occasionally break the rule
when I'm just experimenting, say to find out what a compiler
will do.

-- If you're posting a sample in a newsgroup, you'll want to
make is shorter; anything over something between 72 and 80
characters will get its formatting messed up, and since
follow-up postings, quoting it, will add a few characters to
the beginning, I generally try to limit it to 64 characters.
(On the other hand, like everyone else, I'll copy/paste my
code directly from the original source, so if I post actual
code from elsewhere, it is wider. And its formatting does
get messed up.)

-- If you're concerned purely about readability, look at a
newspaper column. They're sized for maximum readability.
Of English, anyway---I suspect that code follows slightly
different rules. Still, anything over about 60 characters,
*not* including indentation, will probably cause problems
for the reader. See Ian's comments with regards to finding
the start of the next line. I don't know if this is the
reason, but there have been concrete studies on this
subject. (Again, concerning native languages, not code.
And resulting in the optimal length being that of a
newspaper column. In English, anyway.)

So as a general rule: a maximum of 80 characters, total, and
between 60 and 70, without the leading indentation.

 

[Juha Nieminen]

What does interactive programming (whatever that means) have to
do with it?

I meant interactive text editing. With text editing programs.

Fortran restricted line width to 72 characters,
ignoring the last 8 on the card (so that you could put sequence
numbers there---very useful for resorting the code if you
accidentally dropped the deck). The reason most terminals where
80 characters per line is *because* that was the width of the
cards.

I know *why* text terminals were 80 characters wide. What I am saying
is that program source code lines have usually been restricted to 80
characters precisely because *terminals* have been 80 characters wide.
If terminals had been 100 characters wide, then 100 characters would
have been the historical limit. But terminals were not 100 characters
wide but 80 instead (because of the punch cards).

In other words, I'm saying that the 80 character line length is
because of terminals, not because of punch cards. If terminals had
always have some other width, that would have been the historical limit
for source code lines as well.

 

[Chris Ahlstrom]

After takin' a swig o' grog, Hendrik Schober belched out
this bit o' wisdom:

Chris Ahlstrom wrote:
(But then I had never had to look at code at a machine which
only has vi. And hopefully I'll never will. :^> )

What does vi have to do with it? There's GUI vi's. You can even plug
vi (vim) into Visual Studio, apparently.

 

[Chris Ahlstrom]

After takin' a swig o' grog, James Kanze belched out
this bit o' wisdom:

So as a general rule: a maximum of 80 characters, total, and
between 60 and 70, without the leading indentation.

Check out Ch. 32 of BEAUTIFUL CODE, entitled "Code in Motion". Here's
the article it is based on:

http://www.perforce.com/perforce/papers/prettycode.html

Seven Pillars of Pretty Code

Christopher Seiwald

 

[Hendrik Schober]

After takin' a swig o' grog, Hendrik Schober belched out
this bit o' wisdom:


What does vi have to do with it? There's GUI vi's. You can even plug
vi (vim) into Visual Studio, apparently.

If you can do this, you're most likely not on a machine
that only has vi. (And if you are, chances are that you
won't have more than 80 chars per line.)

Schobi

 

[James Kanze]

I meant interactive text editing. With text editing programs.

But I don't see where that really makes a difference. If I'm
editing with a card punch, I have an even more rigorous set of
constraints.

I know *why* text terminals were 80 characters wide. What I am
saying is that program source code lines have usually been
restricted to 80 characters precisely because *terminals* have
been 80 characters wide. If terminals had been 100 characters
wide, then 100 characters would have been the historical
limit. But terminals were not 100 characters wide but 80
instead (because of the punch cards).

In other words, I'm saying that the 80 character line length
is because of terminals, not because of punch cards. If
terminals had always have some other width, that would have
been the historical limit for source code lines as well.

But program source code lines were limited in length long before
terminals (at least those with screens) were around. As I said,
Fortran limited the length to 72 characters. I think you're
confusing cause and effect; early terminals only displayed 80
lines (except that many displayed 132---the width of most
printers at the time) because that's what the existing line
length limits were.

 

[James Kanze]

[...]

(But then I had never had to look at code at a machine which
only has vi. And hopefully I'll never will. :^> )

Not sure what vi has to do with it. Vi displays in whatever the
window width is. The problem is things like the size of paper,
for example (my printer won't handle much larger than A4).

 

[James Kanze]

After takin' a swig o' grog, James Kanze belched out
this bit o' wisdom:

Check out Ch. 32 of BEAUTIFUL CODE, entitled "Code in Motion".
Here's the article it is based on:

Seven Pillars of Pretty Code

Christopher Seiwald

Which starts well, and gets worse as it goes along, ending up
with some of the worst coding practices imaginable.

 

[Hendrik Schober]

After takin' a swig o' grog, Erik Wikström belched out
this bit o' wisdom:

[...]

(But then I had never had to look at code at a machine which
only has vi. And hopefully I'll never will. :^> )

Not sure what vi has to do with it. Vi displays in whatever the
window width is.

I already answered this.

The problem is things like the size of paper,
for example (my printer won't handle much larger than A4).

I can't remember the last time I printed code.

[...]

Schobi

 

[Chris Ahlstrom]

After takin' a swig o' grog, James Kanze belched out
this bit o' wisdom:

Which starts well, and gets worse as it goes along, ending up
with some of the worst coding practices imaginable.

Guess it's all a matter of taste, then.