By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,325 Members | 1,128 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,325 IT Pros & Developers. It's quick & easy.

What's your maximum line size preference?

P: n/a

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
Oct 9 '08 #1
Share this Question
Share on Google+
53 Replies

P: n/a
Gianni Mariani wrote:
>
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.

--
Ian Collins.
Oct 9 '08 #2

P: n/a
Gianni Mariani wrote:
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.
Oct 9 '08 #3

P: n/a
Gianni Mariani wrote:
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.
Readability is a concern in our team because it's a few hundred strong.
Any time you write code, you have to consider that (a) it's not going
to be read by you and (b) if it's going to be read by you, it can be a
year or more later. So, based on that, I would think that if the line
fully fits in my editor's code window, so I don't have to scroll the
window horizontally to read the entire line, the width is acceptable.
Now, it probably means that on the other man's monitor it could be too
long (if the code window isn't as wide as mine), and unfortunately there
is no cure for that. Hopefully, the monitors do get upgraded and if the
line lengths don't change, eventually all lines will fit. <weakG>

Just like any other style element, the line length participates in a
compromise. For example, you can shorten your lines by using shorter
names for variables and functions, but it detracts from readability in
its own, possibly more unpleasant, way.

Whitespace (line breaks included) has an important role in the code
readability, but I would probably say, "don't get hung up on it". The
ability to read and understand any code without wasting too much time on
reformatting is a skill *every programmer* needs to develop.

Just my $0.04...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 9 '08 #4

P: n/a
Juha Nieminen <no****@thanks.invalidwrote:
>Gianni Mariani wrote:
>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,
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.

--
Tim Slattery
Sl********@bls.gov
http://members.cox.net/slatteryt
Oct 9 '08 #5

P: n/a
Tim Slattery wrote:
Juha Nieminen <no****@thanks.invalidwrote:
>Gianni Mariani wrote:
>>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,

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.
Oct 9 '08 #6

P: n/a
On 2008-10-09 11:30, Gianni Mariani wrote:
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.

--
Erik Wikström
Oct 9 '08 #7

P: n/a
Gianni Mariani <gi*******@mariani.wskirjutas:
>
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.
I am trying to keep a single statement on a single line, unless it's
really starting to get off the screen. It seems the longest lines are
about 130-140 characters. Example of a line ending at pos 133:

HtmlCmdHandlerFile* main_file_handler = dynamic_cast
<HtmlCmdHandlerFile*>(HttpServer::InstanceNoStart( ).FindHandler("file"));

And yes, when working on the laptop the ends of some lines are not
visible. Given that vertically the cpp file is not fully visible anyway
on the screen, I have not turned much attention to this, and my
colleagues have not complained either.

Regards
Paavo
Oct 9 '08 #8

P: n/a
Chris Ahlstrom wrote:
>
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!

--
Ian Collins
Oct 10 '08 #9

P: n/a
Chris Ahlstrom wrote:
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 */
)
{
// ....
}
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
Oct 10 '08 #10

P: n/a
On Oct 9, 6:17 pm, Juha Nieminen <nos...@thanks.invalidwrote:
Tim Slattery wrote:
Juha Nieminen <nos...@thanks.invalidwrote:
Gianni Mariani wrote:
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,
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.
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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 10 '08 #11

P: n/a
On Oct 9, 11:30 am, Gianni Mariani <gi4nos...@mariani.wswrote:
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 10 '08 #12

P: n/a
James Kanze wrote:
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.
Oct 10 '08 #13

P: n/a
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.

--
It is only people of small moral stature who have to stand on their dignity.
Oct 10 '08 #14

P: n/a
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

--
The more pretentious a corporate name, the smaller the organization. (For
instance, The Murphy Center for Codification of Human and Organizational Law,
contrasted to IBM, GM, AT&T ...)
Oct 10 '08 #15

P: n/a
Chris Ahlstrom wrote:
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.
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
Oct 10 '08 #16

P: n/a
On Oct 10, 11:18 am, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
What does interactive programming (whatever that means) have
to do with it?
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.
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.
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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 10 '08 #17

P: n/a
On Oct 10, 10:13 am, Hendrik Schober <spamt...@gmx.dewrote:
Chris Ahlstrom wrote:
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. The problem is things like the size of paper,
for example (my printer won't handle much larger than A4).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 10 '08 #18

P: n/a
On Oct 10, 1:42 pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
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
Which starts well, and gets worse as it goes along, ending up
with some of the worst coding practices imaginable.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 10 '08 #19

P: n/a
James Kanze wrote:
On Oct 10, 11:18 am, Juha Nieminen <nos...@thanks.invalidwrote:
>James Kanze wrote:
>>What does interactive programming (whatever that means) have
to do with it?
>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.
Are you *reading* the cards? If you're not, how is *readability*
involved? Wasn't that the issue the OP brought forth? The cards need
to be readable, but not by a human.
[..]
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 10 '08 #20

P: n/a
After takin' a swig o' grog, James Kanze belched out
this bit o' wisdom:
On Oct 10, 1:42 pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
>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

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.

--
You will be successful in love.
Oct 10 '08 #21

P: n/a
James Kanze wrote:
On Oct 10, 1:42 pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
>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

Which starts well, and gets worse as it goes along, ending up
with some of the worst coding practices imaginable.
I'm with you there, horrible.

Use goto to avoid indentation, what was he thinking?

--
Ian Collins
Oct 10 '08 #22

P: n/a
Gianni Mariani wrote:
>
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.
80. Period. Please. It's a hard and fast rule. It's not hard
(despite your claim of "oodles" of wasted time), and it makes my life a
heck of a lot easier.
Oct 10 '08 #23

P: n/a
On Oct 10, 8:31*pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
After takin' a swig o' grog, James Kanze belched out
* this bit o' wisdom:
On Oct 10, 1:42 pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
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
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.
Not really. Some things are a matter of taste, but some of his
recommendations involve proven bad practice. I'd avoid that
site like the plague.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 10 '08 #24

P: n/a
On Oct 10, 9:57*am, Victor Bazarov <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
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.

Are you *reading* the cards? *If you're not, how is *readability*
involved? *Wasn't that the issue the OP brought forth? *The cards need
to be readable, but not by a human.

They have to be readable if you're editing. While we did read the
*programs* off printed listings, you still had to dig into the decks
to make the changes. And for that you had to read the card - which
was why, for source code, you almost always had the text printed
across the top of the card.
Oct 10 '08 #25

P: n/a
James Kanze wrote:
(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.)
Your newsreader may have an option not to wrap outgoing lines. Of
course you'd have to get the prose part wrapped some other way, but
even doing that manually is rather less hazardous than doctoring
pasted code.
Martin

--
He who can be himself shall belong to no one else.
--Paracelsus
Oct 10 '08 #26

P: n/a
ro***********@yahoo.com wrote:
On Oct 10, 9:57 am, Victor Bazarov <v.Abaza...@comAcast.netwrote:
>James Kanze wrote:
>>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.
Are you *reading* the cards? If you're not, how is *readability*
involved? Wasn't that the issue the OP brought forth? The cards need
to be readable, but not by a human.


They have to be readable if you're editing. While we did read the
*programs* off printed listings, you still had to dig into the decks
to make the changes. And for that you had to read the card - which
was why, for source code, you almost always had the text printed
across the top of the card.
Not all card punchers could do that. What we had is a number on the
card that would be the same as the line number on the source printout.
You would *never* have to actually read the card to understand what the
code is doing (which is where the readability is important). You would
only need to read the card to make sure it's the right one just before
replacing it with the updated, in the stack.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 10 '08 #27

P: n/a
Martin Eisenberg wrote:
James Kanze wrote:
(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.)

Your newsreader may have an option not to wrap outgoing lines.
His news system is Google Groups. That doesn't have many options.


Brian
Oct 10 '08 #28

P: n/a
James Kanze wrote:
On Oct 10, 10:13 am, Hendrik Schober <spamt...@gmx.dewrote:
>Chris Ahlstrom wrote:
>>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
Oct 10 '08 #29

P: n/a
On Oct 10, 4:20*pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:
robertwess...@yahoo.com wrote:
On Oct 10, 9:57 am, Victor Bazarov <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
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.
Are you *reading* the cards? *If you're not, how is *readability*
involved? *Wasn't that the issue the OP brought forth? *The cards need
to be readable, but not by a human.
They have to be readable if you're editing. *While we did read the
*programs* off printed listings, you still had to dig into the decks
to make the changes. *And for that you had to read the card - which
was why, for source code, you almost always had the text printed
across the top of the card.

Not all card punchers could do that. *What we had is a number on the
card that would be the same as the line number on the source printout.
You would *never* have to actually read the card to understand what the
code is doing (which is where the readability is important). *You would
only need to read the card to make sure it's the right one just before
replacing it with the updated, in the stack.

By the time the late 60s rolled around, almost all keypunches had, at
least as an option, an "interpret" feature which did the printing. In
the IBM world, you had to go back to the '024 keypunch if you wanted
one that didn't print (its more popular, and otherwise identical,
sibling the '026, did print ). The ‘024 and ‘026 date back to 1949,
and were replaced by the ‘029, which did print, in 1964.

Not to say that I didn’t see more than a few keypunches with broken
printers.

The most common cases where I saw uninterpreted decks was after a deck
was punched from the mainframe, either from a library, or a
duplication of a worn out deck, on the "big" card punch, which
invariable didn't have such a feature. And those were always more of
a pain to deal with because the cards were that much harder to read.

For the life of me I can’t remember which device it was, but there was
a keypunch that had an “interpret existing deck” feature, which you
could feed a deck through it and get it interpreted. Only saw them in
a couple of shops, but they were rather handy at times.
Oct 11 '08 #30

P: n/a
On Oct 10, 4:57*pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
On Oct 10, 11:18 am, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
What does interactive programming (whatever that means) have
to do with it?
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.
Are you *reading* the cards? *If you're not, how is
*readability* involved? *Wasn't that the issue the OP brought
forth? *The cards need to be readable, but not by a human.
Not in the sense we use the term. The point is that the 80
character limit is imposed technically, and that the reason
technical issues impose it ultimately goes back to the punched
card (which also imposed it technically). I certainly don't
think that there's a hard limit that says that 79 characters is
perfectly readable, and 81 isn't---there are even special cases
(e.g. table initializations) where the 80 character limit
reduces readability (although most of the time, you really want
even less).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 11 '08 #31

P: n/a
On Oct 10, 7:51*pm, Hendrik Schober <spamt...@gmx.dewrote:
James Kanze wrote:
[...]
* * * * * * * * * The problem is things like the sizeof paper,
for example (my printer won't handle much larger than A4).
* I can't remember the last time I printed code.
Code review.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 11 '08 #32

P: n/a
On Oct 10, 11:42*pm, "Default User" <defaultuse...@yahoo.comwrote:
Martin Eisenberg wrote:
James Kanze wrote:
(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.)
Your newsreader may have an option not to wrap outgoing lines.
His news system is Google Groups. That doesn't have many options.
And even if it did, I don't know the width of the window the
reader will have---if my outgoing software doesn't wrap it, his
reading software might. It's just common politeness to format
your outgoing posts to a maximum of, say, 64 characters
(allowing quoted sections to be correspondingly longer).

Similarly, if you're publishing in a magazine, they're likely to
impose a limit, so that the code will not be wider than one
common. Something like 40 characters.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 11 '08 #33

P: n/a
James Kanze wrote:
On Oct 10, 7:51 pm, Hendrik Schober <spamt...@gmx.dewrote:
>James Kanze wrote:

[...]
>> 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.

Code review.
What's one of those ? :)

--
Ian Collins
Oct 11 '08 #34

P: n/a
Jeff Schwab wrote:
80. Period. Please. It's a hard and fast rule.
Does that count the newline at the end of the line or not?
Oct 11 '08 #35

P: n/a
After takin' a swig o' grog, Ian Collins belched out
this bit o' wisdom:
James Kanze wrote:
>On Oct 10, 1:42 pm, Chris Ahlstrom <lino...@bollsouth.nutwrote:
>>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

Which starts well, and gets worse as it goes along, ending up
with some of the worst coding practices imaginable.
I'm with you there, horrible.

Use goto to avoid indentation, what was he thinking?
I agree with that, and would refactor to avoid excessive indentation.

The book chapter, as far as I can tell, does not recommend gotos to
avoid indentation <grin>.

--
For your penance, say five Hail Marys and one loud BLAH!
Oct 11 '08 #36

P: n/a
After takin' a swig o' grog, James Kanze belched out
this bit o' wisdom:
Not in the sense we use the term. The point is that the 80 character limit is imposed technically, and that the reason technical issues impose it ultimately goes back to the punched card (which also imposed it technically). I certainly don't think that there's a hard limit that says that 79 characters is perfectly readable, and 81 isn't---there are even special cases (e.g. table initializations) where the 80 character limit reduces readability (although most of the time, you really want even less).
(Reformatted for readability.)

--
Q: Why shouldn't I simply delete the stuff I never use, it's just taking up
space?
A: This question is in the category of Famous Last Words..
-- From the Frequently Unasked Questions
Oct 11 '08 #37

P: n/a
Juha Nieminen wrote:
Jeff Schwab wrote:
>80. Period. Please. It's a hard and fast rule.

Does that count the newline at the end of the line or not?
Not usually. :)
Oct 11 '08 #38

P: n/a
Jeff Schwab wrote:
Juha Nieminen wrote:
>Jeff Schwab wrote:
>>80. Period. Please. It's a hard and fast rule.

Does that count the newline at the end of the line or not?

Not usually. :)
Well, that may present a problem with lines which have exactly 80
characters (without counting the newline at the end): Some editors will
wrap and then print the newline, which will cause the next line to look
empty, while others won't do that.
Oct 11 '08 #39

P: n/a
Juha Nieminen wrote:
Jeff Schwab wrote:
>Juha Nieminen wrote:
>>Jeff Schwab wrote:
80. Period. Please. It's a hard and fast rule.
Does that count the newline at the end of the line or not?
Not usually. :)

Well, that may present a problem with lines which have exactly 80
characters (without counting the newline at the end): Some editors will
wrap and then print the newline, which will cause the next line to look
empty, while others won't do that.
I've never seen an editor do that, although I have seen command-line
shells do it; do you have a particular editor in mind?

Emacs wraps after only 79 characters by default, because it adds a
pre-emptive backslash (or other symbol) to show the wrapping. I see
that as more of a shortcoming of the editor's default configuration than
an issue with the code, though. If I worked in an environment where it
were an issue, of course, I wouldn't mind limiting the code to 78
columns, in the same way that I limit it to 72 characters when including
it inline in email, or 68 characters when posting on Usenet.
Oct 11 '08 #40

P: n/a
In article <48********@news.mel.dft.com.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>
Do you have a preference on maximum line width for C++ code?
I'll go against the grain and stay that IMO, 80 characters per line is
an outdated standard which is only useful for situations where codes
is viewed using very old technology.

By all mean, don't go wild and make 200 characters lines, but on the
other hand, I find that a hard 80 characters limit can results in too
much vertical white space which lowers readability. Vertical
scrolling is annoying too, not only horizontal scrolling.

So personally, I aim toward a soft 80-ish characters line but use
judgement to decide if the code will be clearer with an overflowing
line or a splitted line.

Typically, most lines fall under the 80 soft limit. However, some
overflow. Typically, the most common cases are:

Right hand side comments. e.g.
int angle; ///< angle in degree between .... ... (range 0..180)

(such a line clarifying something gain very little from being split
and in fact splitting them obfuscate the rest of the code because the
clarification is not something that you want to refer to most of the
time so it is good to have it less in your face)

Comments, especially doxygen ones

/// \param[in] angle ...

Function/method declaration
class Foo
{
public:
void bar(..., std::string const & logfile = DEFAULT_LOGFILE);
}

Now, there can easily be cases with foo, logfile and/or
DEFAULT_LOGFILE becoming longuer identifiers where it is almost
impossible to split that in line usefully or readably.

Function/method calls where they just about overflow the 80 chars.

templates where trying to keep everything below 80 chars while
respecting indentation might end up requiring 3-4 lines

Anyway, my contrary 2 pennies

Yannick

Oct 14 '08 #41

P: n/a
yt******@nyx.nyx.net (Yannick Tremblay) writes:
In article <48********@news.mel.dft.com.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>>
Do you have a preference on maximum line width for C++ code?

I'll go against the grain and stay that IMO, 80 characters per line is
an outdated standard which is only useful for situations where codes
is viewed using very old technology.
Of course. But how can you be sure there won't be some terrorist
attack by EMP bomb this night? Then tomorrow morning, you'll be happy
if you can still read your sources on a 132-column line printer and
type them back into your electro-mechanical computer using 80-column
punch cards.

That's why I keep all my programs in uppercase even! :-)

By all mean, don't go wild and make 200 characters lines, but on the
other hand, I find that a hard 80 characters limit can results in too
much vertical white space which lowers readability. Vertical
scrolling is annoying too, not only horizontal scrolling.
Yes. When you can keep calm your paranoid neurons, go ahead, and use the horizontal space available. Nowdays, splitting a screen
in two gives you a lot of horizontal space, even with readable fonts. As long as you don't go beyond the 132-column limit of a
line printer, I'll be OK with it.

There's also a trick to increase the available column count: use a proportional font. I know that with a lot of programming
languages I don't like that, but with the best programming languages, only the left indentation is really used most of the time,
so you can easily use a proportional font, and tuck 160 or 200 proportional characters where only 80 or 100 Courier characters
would stand.

There's also the question of the column width. It's better for the readability to use narrower columns. 80 columns is narrow
enough. If you need to typeset your code in a scientific paper, it'll be easier if you format it in 80 columns or even less.
That's a good reason why C++ templates shouldn't be used in scientific papers, lisp or haskell are better formated there. :-)

--
__Pascal Bourguignon__
Oct 14 '08 #42

P: n/a
James Kanze wrote:
On Oct 10, 7:51 pm, Hendrik Schober <spamt...@gmx.dewrote:
>James Kanze wrote:

[...]
>> 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.

Code review.
Beamers.

Schobi
Oct 14 '08 #43

P: n/a
On 14 Oct 2008 12:48:31 GMT, yt******@nyx.nyx.net (Yannick Tremblay)
wrote:
>In article <48********@news.mel.dft.com.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>>
Do you have a preference on maximum line width for C++ code?

I'll go against the grain and stay that IMO, 80 characters per line is
an outdated standard which is only useful for situations where codes
is viewed using very old technology.
I set two markers - one at 80 and one at 132. Both are guides, not
absolutes. Both figures are obviously taken from old VT standards.

Narrow code can be useful when you need two or more listings on
screen, but there's always horizontal splitters, multiple monitors,
widescreen monitors etc.

But as you say, most lines are nowhere near 80 chars, let alone 132.
And with the few lines that do get long, there's usually vertical
alignment benefits to line-splitting anyway.

Often, very long lines mean you should be using some kind of alias or
indirection (typedef, access method, reference variable or whatever)
or perhaps a using clause. But even decluttering is about readability
rather than line length.

Oct 15 '08 #44

P: n/a
On Tue, 14 Oct 2008 15:23:01 +0200, pj*@informatimago.com (Pascal J.
Bourguignon) wrote:
>There's also a trick to increase the available column count: use a proportional font. I know that with a lot of programming
languages I don't like that, but with the best programming languages, only the left indentation is really used most of the time,
so you can easily use a proportional font, and tuck 160 or 200 proportional characters where only 80 or 100 Courier characters
would stand.
You use tab for indentation and vertical alignment, don't you. Come on
- confess your sins ;-)

Oct 15 '08 #45

P: n/a
In article <6i********************************@4ax.com>,
Stephen Horne <sh********@blueyonder.co.ukwrote:
>On 14 Oct 2008 12:48:31 GMT, yt******@nyx.nyx.net (Yannick Tremblay)
wrote:
>>In article <48********@news.mel.dft.com.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>>>
Do you have a preference on maximum line width for C++ code?

I'll go against the grain and stay that IMO, 80 characters per line is
an outdated standard which is only useful for situations where codes
is viewed using very old technology.

I set two markers - one at 80 and one at 132. Both are guides, not
absolutes. Both figures are obviously taken from old VT standards.

Narrow code can be useful when you need two or more listings on
screen, but there's always horizontal splitters, multiple monitors,
widescreen monitors etc.
Don't get me wrong. The huge majority of my code is less than 80
chars. I do appreciate narrow simple lines. Just that I dislike a
hard rule that nothing should ever be wider than 80 chars because IMO
it is outdated and results in lower readability.
>Often, very long lines mean you should be using some kind of alias or
indirection (typedef, access method, reference variable or whatever)
or perhaps a using clause. But even decluttering is about readability
rather than line length.
Indeed, the goal is readability and clarity. Very long lines tend to
be less readable. But at the same time, try reformatting the average
code as 40 chars columns. This would also make the code less
readable. IMO a hard 80 chars column also introduces readability
compromises that are undesireable (although to a much much lesser
extend).

In the same way that I think that functions should be kept shorts,
I will not put a hard rule that no function should ever be longer than
20 lines. I prefer guidelines with judgement applied.

Yannick
Oct 15 '08 #46

P: n/a
In article <12***************@irys.nyx.net>, yt******@nyx.nyx.net (Yannick
Tremblay) wrote:

[...]
Don't get me wrong. The huge majority of my code is less than 80
chars. I do appreciate narrow simple lines. Just that I dislike a
hard rule that nothing should ever be wider than 80 chars because IMO
it is outdated and results in lower readability.
If the huge majority of your code's lines are less than 80 characters, how
could limiting those few other lines make a big impact on readability?

[...]
But at the same time, try reformatting the average
code as 40 chars columns. This would also make the code less
readable.
And reformatting average code to 10-character lines would make it less
readable as well.
I prefer guidelines with judgement applied.
I agree; guides, not hard rules (in most cases).
Oct 15 '08 #47

P: n/a
Gianni Mariani wrote:
>
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
None

I will only insert an EOF character according to my own rule as follows:

1. After a semicolon
2. After the head part of conditional sentence (if, then, for, do,
while, switch, etc)
3. After {
Oct 15 '08 #48

P: n/a
On 15 Oct 2008 09:00:50 GMT, yt******@nyx.nyx.net (Yannick Tremblay)
wrote:
>In the same way that I think that functions should be kept shorts,
I will not put a hard rule that no function should ever be longer than
20 lines. I prefer guidelines with judgement applied.
Yes, agreed. Even a thousand line function need not be split, if it's
just a do-this-then-that sequence. Why break it up - all you do is
obscure the sequence. Unless there's a logical way to group it into
subsequences, which obviously there usually is.

That said, this is one area where my principles don't really match up
to reality. I'm terrible for growing huge functions that really need
refactoring, but never getting around to it. 99% of my functions are
still pretty small, of course, but there's some evil lurking in there
for sure.

Oct 15 '08 #49

P: n/a
On 15 Oct, 14:13, Michael <mich...@michaeldadmum.no-ip.orgwrote:
Gianni Mariani wrote:
Do you have a preference on maximum line width for C++ code?
<snip>
I will only insert an EOF character according to my own rule as follows:

1. After a semicolon
2. After the head part of conditional sentence (if, then, for, do,
while, switch, etc)
3. After {
and END-OF-FILE character?!

Oct 15 '08 #50

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.