What's your maximum line size preference?

[Ian Collins]

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?

 

[James Kanze]

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

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.

 

[robertwessel2]

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.

 

[Martin Eisenberg]

(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

 

[Default User]

Your newsreader may have an option not to wrap outgoing lines.

His news system is Google Groups. That doesn't have many options.




Brian

 

[robertwessel2]

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.

 

[James Kanze]

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]

James Kanze wrote:

[...]

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

Code review.

 

[James Kanze]

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.

 

[Ian Collins]

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 ?

 

[Juha Nieminen]

80. Period. Please. It's a hard and fast rule.

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

 

[Chris Ahlstrom]

After takin' a swig o' grog, Ian Collins belched out
this bit o' wisdom:

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

 

[Chris Ahlstrom]

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.)

 

[Juha Nieminen]

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.

 

[Hendrik Schober]

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

 

[Pascal J. Bourguignon]

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.

 

[Stephen Horne]

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.

 

[Stephen Horne]

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 ;-)

 

[Michael]

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 {

 

[Stephen Horne]

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.