From: Beman Dawes (beman_at_[hidden])
Date: 2000-03-14 12:32:32
At 09:06 AM 3/14/00 -0600, Ed Brey wrote:
>... for any given code formatting,
>there is always a tradeoff between scrolling requirements.
>reduces horizontal scrolling at the expense of vertical scrolling.
>generally trades off easy access to code details versus easy access
>structure. Often the details are more important.
>In my experience, I've found that the best tool for trying to get
>of both worlds is to use a proportional font. This buys a
>amount of real estate, and actually improves text readability (just
>does for books). Of course, this introduces another trade-off
>easier access to structure and details versus intra-line alignment,
>helps when consecutive lines have similar format. My personal
>that ever since the advent of syntax highlighting, the alignment
>outweighed by the structure and detail access benefit.
I would be interested in hearing some details of how you use
proportional fonts. I have tried a couple of times and was very
unhappy with the results.
What guidelines do you use? How do you deal with the issues you
raise below? What font? What printing program? What indenting
style works best? How do other programmers react to your code? What
happens when you port the code between operating systems? Does code
that looks good under Windows still look good under Unix or on a Mac?
Do you have some sample code you could let us see?
>Proportional fonts throws a monkey wrench into the proposed
>least with regard to the library that I am tinkering with. For one,
>undermines the strict tabs to spaces rule. Since there is no
>alignment, tabs are only used for indentation. In this usage, the
>capability of tabs to be sized differently is a benefit, because it
>each user to view the code in the most personally pleasing manner.
>spaces are used, each user is forced into a given indentation size
>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
>width limitation because there is no visual limitation of when the
>limit is being reached.
Sorry to bombard you with so many questions, but I suspect a number
of readers will be interested in your responses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk