[boost] Re: Guidelines for library submissions

From: Ed Brey (brey_at_[hidden])
Date: 2000-03-14 10:06:05

From: "Miki Jovanovic" <miki_at_[hidden]>
> beman dawes <bema-_at_[hidden]> wrote:
> > Limit line
> > lengths to 80 characters; that prevents truncation or line wraps when
> > printing of your source code.
>
> Well, I will probably get beaten up on this, but I am strongly against
> this policy. I have not printed a line of code in 3-4 years, and am
> quite happy looking at long lines. As a matter of fact, I find
> splitting lines much more disruptive then having to occasionaly scroll.
> Long lines are generally made out of function calls with many
> parameters, and understanding exactly what parameters do is a very odd
> occasion. However, reviewing the overall structure of a method/function
> is much more common task, and having 2-3 statements fill the whole
> screen is very disruptive.

I'd second this and would stress further for any given code formatting,
there is always a tradeoff between scrolling requirements.  Shortening lines
reduces horizontal scrolling at the expense of vertical scrolling.  This
generally trades off easy access to code details versus easy access to code
structure.  Often the details are more important.

In my experience, I've found that the best tool for trying to get the best
of both worlds is to use a proportional font.  This buys a substantial
amount of real estate, and actually improves text readability (just as it
does for books).  Of course, this introduces another trade-off between
easier access to structure and details versus intra-line alignment, which
helps when consecutive lines have similar format.  My personal experience is
that ever since the advent of syntax highlighting, the alignment benefit it
outweighed by the structure and detail access benefit.

Proportional fonts throws a monkey wrench into the proposed conventions, at
least with regard to the library that I am tinkering with.  For one, it
undermines the strict tabs to spaces rule.  Since there is no reliance on
alignment, tabs are only used for indentation.  In this usage, the
capability of tabs to be sized differently is a benefit, because it allows
each user to view the code in the most personally pleasing manner.  If
spaces are used, each user is forced into a given indentation size for no
benefit.  The other monkey wrench is that the number of characters on a line
becomes irrelevant because it does not determine the line width, and
moreover, it is very tedious to try to format the code to maintain a line
width limitation because there is no visual limitation of when the arbitrary
limit is being reached.