79 chars or more?

[AK]

As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I have to edit files in 80 width
terminals, it's still easier to adapt to some inconvenience when that
happens than the other way around, since about 95% of time or more, I do
use wider editor window or terminal.

Is going over 79 still a terrible thing to do? -andrei

 

[Steven D'Aprano]

As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I have to edit files in 80 width
terminals, it's still easier to adapt to some inconvenience when that
happens than the other way around, since about 95% of time or more, I do
use wider editor window or terminal.

Is going over 79 still a terrible thing to do? -andrei

For your own code, you are free to do anything you like

But if you want to submit code to the Python standard library, you have
to restrict lines to 79 characters. This is no different from any other
project -- you need to stick to the project's coding conventions.


There are still good reasons to stick with 79 chars, even on large screen
monitors. People with poor vision will appreciate being able to increase
the font size. Others might like to have two windows side-by-side, each
showing 79 characters. Some people don't have wide monitors.

 

[AK]

For your own code, you are free to do anything you like

But if you want to submit code to the Python standard library, you have
to restrict lines to 79 characters. This is no different from any other
project -- you need to stick to the project's coding conventions.


There are still good reasons to stick with 79 chars, even on large screen
monitors. People with poor vision will appreciate being able to increase
the font size. Others might like to have two windows side-by-side, each
showing 79 characters. Some people don't have wide monitors.

There's no doubt that there are pro's and con's, but to be fair, it's
not like code becomes unreadable over 79 chars - the difference is that
when your terminal is 80 chars, it's less convenient for you to read
code that's wider and when your terminal is wider, it's less convenient
to read code that's 79 chars.

I guess I'm just curious what percentage of people prefer 79chars - is
it 5/95% or 15/85% or 50/50? -andrei

 

[James Mills]

There's no doubt that there are pro's and con's, but to be fair, it's
not like code becomes unreadable over 79 chars - the difference is that
when your terminal is 80 chars, it's less convenient for you to read
code that's wider and when your terminal is wider, it's less convenient
to read code that's 79 chars.

I guess there are two-sides to the coin here so to speak. See I'm
vision impaired
so I prefer a 79 char width in my own projects and expect those that work
with me to use the same standards (stick to project standards as Steven says).

The other side is this... I'm of the opinion that if you're writing a
line of code
that's excessively long (>80char or say >100chars), then you might want to
reconsider what you're doing (It might be wrong).

cheers
james

 

[AK]

I guess there are two-sides to the coin here so to speak. See I'm
vision impaired
so I prefer a 79 char width in my own projects and expect those that work
with me to use the same standards (stick to project standards as Steven says).

The other side is this... I'm of the opinion that if you're writing a
line of code
that's excessively long (>80char or say>100chars), then you might want to
reconsider what you're doing (It might be wrong).

I stay away from ugly cramped one-liners; I mostly run over 79 when I
have a few `and` and `or` clauses or long strings. I've also noticed
something interesting: going from 79 to 99 affects a relatively large
number of lines, but going over 99 (i.e. 99 to 132) is much, much rarer.

By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..

-andrei

 

[James Mills]

By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..

In my opinion it would be "okay" to teach. However:

Bare in mind other considerations for smaller width
conventions and the reasons for them. Make your
students aware of standards and get them into the
habit of following standards early on.

cheers
James

 

[Michael Torrie]

I stay away from ugly cramped one-liners; I mostly run over 79 when I
have a few `and` and `or` clauses or long strings. I've also noticed
something interesting: going from 79 to 99 affects a relatively large
number of lines, but going over 99 (i.e. 99 to 132) is much, much rarer.

I have found something similar, despite my previous post. But you can
normally break the and and or long clauses with backslash
line-continuators. You can also break strings similarly:

a = "This is a really long line that ordinarily would " \
"be long. Test message: %s " % ( message_string)

By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..

I wouldn't worry about it if I were you. Once they know how to program
in Python then you can work on that. Probably more important to be
taught the reasons behind PEP8. You could probably say that many coders
recommend that lines not exceed 80 characters, and state that code in
the standard library has to be less than that, but that on occasion
longer lines are probably not going to kill them.

 

[Lawrence D'Oliveiro]

As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files?

WHAT 79-character limit in source files?

I currently have my Emacs windows set at 100 characters wide, and I’m
thinking of going wider.

Remember, the old hardcopy terminals used to produce 132-character-wide
listings.

 

[Michele Simionato]

On 08/17/2010 12:26 AM, James Mills wrote:
By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..

   -andrei

It is certainly NOT useful to teach a convention which is explicitly
discouraged in the Python guidelines (PEP 8). Having said that, I
particularly *hate* people using long lines, and I usually reindent
the code of my coworkers not following that convention.
The reason is that my Emacs is set to 79 chars and longer code looks
ugly, that I look at two-side diffs all the time, and that sometimes I
want to print on paper the code I have to work with. OTOH, I do not
see a single advantage in using long lines.

Michele Simionato

 

[Jean-Michel Pichavant]

It is certainly NOT useful to teach a convention which is explicitly
discouraged in the Python guidelines (PEP 8). Having said that, I
particularly *hate* people using long lines, and I usually reindent
the code of my coworkers not following that convention.
The reason is that my Emacs is set to 79 chars and longer code looks
ugly, that I look at two-side diffs all the time, and that sometimes I
want to print on paper the code I have to work with. OTOH, I do not
see a single advantage in using long lines.

Michele Simionato

Using long lines can sometimes improve readability, procude better
shaped code, 'cause wrapping code to 79 chars may not be "natural" in
all cases.

We do have a strong habit using meaningfull & plain names in our code,
no i, j, k ; cmdLine is always replaced by commandLine. So lines can
easily exceed 79 chars and wrapping it would'nt be easy.
I'm not saying wrapping to 79 is wrong, I'm just saying that they are
advantages of using long lines (the 1st obvious one being not to care
about wrapping text).

Saying that, if one intend to distribute its code, he should stick to 80
chars per line.

JM

 

[BartC]

I guess there are two-sides to the coin here so to speak. See I'm
vision impaired
so I prefer a 79 char width in my own projects

That's not a good argument for everyone else to do the same. Someone else
might prefer 40 columns for similar reasons.

(Anyway can't a 100-column width be squeezed into the same angular field as
80-columns, just by using a narrower font, when necessary? Assuming the
problem is field width rather than acuity)

The other side is this... I'm of the opinion that if you're writing a
line of code
that's excessively long (>80char or say >100chars), then you might want to
reconsider what you're doing (It might be wrong).

I generally use 100 columns. It's useful for being able to write same-line
comments with meaningful content...

(I've used 80-column hardware (teletypes and such) years ago, I thought such
restrictions had vanished long ago)

 

[Roy Smith]

WHAT 79-character limit in source files?

I currently have my Emacs windows set at 100 characters wide, and I’m
thinking of going wider.

Remember, the old hardcopy terminals used to produce 132-character-wide
listings.

Those of you who think "old hardcopy terminals" did 132 wide obviously
don't remember the ASR-33

 

[Terry Reedy]

WHAT 79-character limit in source files?

Only for stdlib. Python itself has no particular limit.

The dev discussed the issue perhaps a year ago. Enough people wanted or
needed the current stdlib limit that they decided to stick with it.

A reason not mentioned much is that some people have trouble following
packed lines that are too much longer. Wide-page textbooks routinely put
text in two columns for easier reading. This is less of a factor with
jagged edge text, but if the limit were increased to say 150, there
would be people writing multi-line 150 char wide text blocks.

 

[Nobody]

As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I have to edit files in 80 width
terminals, it's still easier to adapt to some inconvenience when that
happens than the other way around, since about 95% of time or more, I do
use wider editor window or terminal.

Is going over 79 still a terrible thing to do? -andrei

If the the limit isn't 79, then what is it? Or are 1000-column lines okay?

Often, simply having a convention is more important than the precise
details. E.g. I don't particularly care how I configure my text editor's
auto-formatting settings, but I do care about not having to change those
settings for each file.

For code which will never be read or edited by anyone other than yourself,
use whatever conventions you want. If you're going to publish the code,
it's a good idea to stick to established standards (80-column lines,
8-column tabs, no gratuitous use of non-ASCII characters, etc).

Apart from "altruistic" reasons, bear in mind that the next time you apply
for a job, the employer may look at your code not just to determine your
programming competence, but also whether you're likely to be a "team
player". Code which doesn't follow normal conventions says "I've only ever
worked on my own, not with other people".

I can't stress enough how big a factor this is. Writing code by yourself
and working as part of a team are almost entirely different skills. Anyone
who regularly hires programmers will be only too aware of the difference.

 

[BartC]

Those of you who think "old hardcopy terminals" did 132 wide obviously
don't remember the ASR-33

ASR33s I think might have been 72 columns wide (and punched cards had a
similar restriction).

However, lineprinter output was more likely to be 132 columns.

 

[Roy Smith]

Those of you who think "old hardcopy terminals" did 132 wide obviously
don't remember the ASR-33

ASR33s I think might have been 72 columns wide (and punched cards had a
similar restriction).[/QUOTE]

Yeah, I was trying to remember if it was 72 or 80. Hmmm, looks like
you're right, it *is* 72 (http://www.pdp8.net/asr33/asr33.shtml).

Punched cards (at least the common ones used by an 029 or 129 punch
machine) were 80 columns. The 72 column restriction was an artificial
one imposed by some programming languages such as Fortran. Columns
73-80 could be used to punch a sequence number, so that if you dropped
your deck, you could re-assemble it by running it through a card sorter.

However, lineprinter output was more likely to be 132 columns.

Yeah, but I wouldn't call a line printer a "terminal".

 

[BartC]

ASR33s I think might have been 72 columns wide (and punched cards had a
similar restriction).

Yeah, I was trying to remember if it was 72 or 80. Hmmm, looks like
you're right, it *is* 72 (http://www.pdp8.net/asr33/asr33.shtml).

Punched cards (at least the common ones used by an 029 or 129 punch
machine) were 80 columns. The 72 column restriction was an artificial
one imposed by some programming languages such as Fortran. Columns
73-80 could be used to punch a sequence number, so that if you dropped
your deck, you could re-assemble it by running it through a card sorter.[/QUOTE]

I'm sure there was a continuation column too. That would mean long lines had
to be split up, but if the width was longer, that would not be necessary.

Yeah, but I wouldn't call a line printer a "terminal".

Source code tended to be perused and marked up on a printout, then corrected
at a terminal. So the terminal's width was less important, until fast VDUs
came in then printouts were used less, and it made sense to adjust to common
25x80 displays.

(I tend to use 60x100 now, sometimes even wider; editing using 25x80 now is
like doing keyhole surgery...)

 

[Lawrence D'Oliveiro]

(I tend to use 60x100 now, sometimes even wider; editing using 25x80 now
is like doing keyhole surgery...)

And yet some people still think sticking to fewer columns is a good idea.

 

[Lawrence D'Oliveiro]

A reason not mentioned much is that some people have trouble following
packed lines that are too much longer. Wide-page textbooks routinely put
text in two columns for easier reading.

But even 79 columns is too wide for them. So what?

 

[Steven D'Aprano]

But even 79 columns is too wide for them. So what?

I think you're wrong.

I just opened a random text book at a random page, and the first line I
counted had 84 columns of text.

("Data Structures and Program Design", 2nd Edition, by Robert L Kruse.)

Of course source code is written in a monospaced typeface, which is a
little wider and consequently fewer characters per page. The book uses
right-justified comments, making it easy to count that the maximum line-
width used for source code is 79 columns. Most lines are *much* shorter.
Excluding comments, the longest line of code I spotted was 64 columns,
with a typical line being more like 40 columns.