Line length for code?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Line length for code?

Rik-4
1/23/16

jwe,

In changeset 21133:31674b9d202b, "NEWS: Refill text to 72 columns", a
documentation file was wrapped to 72 rather than 80 characters.  In
appendix C of the manual on "Tips and Standards" we have "Format the
documentation string so that it fits within an 80-column screen."  I don't
think we need to worry about people using terminals that only display 75
characters anymore.  Even 80 characters is not really an issue anymore.

At any rate, I've had my editor set to wrap code lines at 80 characters for
years now so there is a lot of the code base that is wrapped to that length
rather than 72.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Line length for code?

Oliver Heimlich
On 23.01.2016 23:19, Rik wrote:

> 1/23/16
>
> jwe,
>
> In changeset 21133:31674b9d202b, "NEWS: Refill text to 72 columns", a
> documentation file was wrapped to 72 rather than 80 characters.  In
> appendix C of the manual on "Tips and Standards" we have "Format the
> documentation string so that it fits within an 80-column screen."  I don't
> think we need to worry about people using terminals that only display 75
> characters anymore.  Even 80 characters is not really an issue anymore.
>
> At any rate, I've had my editor set to wrap code lines at 80 characters for
> years now so there is a lot of the code base that is wrapped to that length
> rather than 72.
>
> --Rik

From Wikipedia, s.v., “Characters per line”:
        Many plain text documents still conform to 72 characters per line (CPL)
out of tradition. RFC 2046, which defines the text/plain MIME type, is
itself a 72 CPL plain text.

Then, the default column width in makeinfo is 72. Any documentation
string in Octave gets rewrapped to 72 characters anyway when you call
“help function”. Calling “news” is an exception to this, because the
NEWS file in 4.0.0 is 80 characters wide and has been formatted manually
in the text file.

The NEWS file of the interval package has been formatted by Texinfo, so
“news interval” shows a 72 columns text. IMHO, having a fixed CPL limit
in times of big screens, proportional fonts, auto-wrapping text editors
and post-processors like Texinfo is deprecated. Also it is much easier
to work with version control if you use techniques like this:
http://rhodesmill.org/brandon/2012/one-sentence-per-line/

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Line length for code?

John W. Eaton
Administrator
In reply to this post by Rik-4
On 01/23/2016 05:19 PM, Rik wrote:

> In changeset 21133:31674b9d202b, "NEWS: Refill text to 72 columns", a
> documentation file was wrapped to 72 rather than 80 characters.  In
> appendix C of the manual on "Tips and Standards" we have "Format the
> documentation string so that it fits within an 80-column screen."  I don't
> think we need to worry about people using terminals that only display 75
> characters anymore.  Even 80 characters is not really an issue anymore.
>
> At any rate, I've had my editor set to wrap code lines at 80 characters for
> years now so there is a lot of the code base that is wrapped to that length
> rather than 72.

I still tend to open terminal windows in a fixed-width font with a size
of 80 columns and 24 lines.  My Emacs window opens with a fixed-width
font and a width of 80 characters, though I almost always use more than
24 lines now.  I can learn new habits and use different sizes.  I don't
think there is anything magic about 72 or 80 or some other number of
columns.

Given that I use terminal and editor windows that are 80 columns wide
I have a few reasons for wrapping at less than 80 columns.  One is a
personal preference, one is a practical issue, and another is somewhere
in between.

The personal preference is that I think it is easier to read when the
text stops short of the right margin.  But I don't have a similar
problem with the text starting all the way over on the left margin of
the terminal window.  So I probably prefer things this way just because
I'm used to it.

The practical matter is that Emacs inserts a '\' character at the end of
wrapped lines as a marker to indicate that the line is long.  So if the
line is exactly 80 characters wide, Emacs inserts the '\' marker
character and pushes the last real character to the next the beginning
of the next line and that's kind of annoying.  Yes, I could disable that
feature.  Or use a wider terminal.

The other reason is that lines that are too long tend to be hard to
read.  I would guess that almost no one wants to read lines that are
1000 or even 500 characters wide.  But exactly where to break the lines
is a bit of a personal preference.

These days (I mean, since about 1990) with terminals that can be just
about any size and that can do line breaking between words
automatically, we probably shouldn't be forcing any line breaks on
users, or assume that they will be reading in a fixed-width font on any
particular size terminal window (though we may force a fixed-width font
for verbatim text, but that's a separate issue).

Maybe the best thing we could do would be to convert the NEWS file and
other informational documents that we distribute to some format that can
be viewed properly on whatever output device.  We can still generate and
provide an old-school text version of the NEWS file with lines wrapped
to whatever length people think is appropriate.  But then we could also
automatically generate an HTML or PDF version of the file for the web or
the GUI that will look good no matter what the width of the terminal or
browser window is.

As for source files, maybe the suggestion to put "sentences" on single
lines is worth trying?  In some cases, we would have some very long
lines (for example, the parameter list of some Fortran functions).  But
maybe this is not as much of a problem as the constant reformatting due
to manual line wrapping and the trouble that can cause for diffs.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Line length for code?

Colin Macdonald-2
On 02/02/16 11:35, John W. Eaton wrote:
> As for source files, maybe the suggestion to put "sentences" on single
> lines is worth trying?  In some cases, we would have some very long
> lines (for example, the parameter list of some Fortran functions).

My opinion/interpretation of this practice, is that each sentence should
*start* on a new line, but that sentence could wrap at 72/80/whatever.
This works well, for example, with LaTeX or texinfo and revision control
systems.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Line length for code?

John W. Eaton
Administrator
On 02/02/2016 02:50 PM, Colin Macdonald wrote:
> On 02/02/16 11:35, John W. Eaton wrote:
>> As for source files, maybe the suggestion to put "sentences" on single
>> lines is worth trying?  In some cases, we would have some very long
>> lines (for example, the parameter list of some Fortran functions).
>
> My opinion/interpretation of this practice, is that each sentence should
> *start* on a new line, but that sentence could wrap at 72/80/whatever.
> This works well, for example, with LaTeX or texinfo and revision control
> systems.

Yes, but it can also be useful to avoid inserting literal newline
characters in long lines, especially if the output is displayed in a
narrow terminal window that further wraps but respects literal newline
characters.  Then you can end up with a bit of a jumbled mess.

jwe