[boost] Re: Guidelines for library submissions

From: Ed Brey (brey_at_[hidden])
Date: 2000-03-15 09:45:39

[Working with source code using proportional fonts.]

From: "Beman Dawes" <beman_at_[hidden]>
> >- There is no arbitrary line-length limit.  Statements are broken
> >onto multiple lines based on their complexity, so as to optimize
the
> >tradeoff between horiztonal and vertical scrolling.
>
> I personally do a great deal of alignment within lines of code, and
> particularly within comments.  Whole tables of information
sometimes.
>  I don't think I could give that up.  The lack of intra-line
> alignment (presumably because the number of tabs would depend on the
> font) is a killer.

There are certainly instances where alignment provides such a huge
advantage that it outweighs the advantages of proportional fonts,
although often in these cases, the alignment is for comments that may
be even better presented in an external html or graphical doc, which
provides much richer fomatting than aligned ASCII.

In general, I believe there is no one right answer.  The optimal
presentation of the source code depends on the nature of the program
being developed and the internal brain workings of the reader/writer
of the code.  To the extent reasonable, I'd like to see the boost
conventions provide the least restrictive set of possibilities from
which a contributer, reviewer, or user can choose an optimal
presentation.

Specifically, my recommendation would be:
- No specification of fixed versus proportional fonts. Reader/writer
chooses.
- No requirement or nonrequirement of alignment. A writer can choose
to include alignment, in which case the reader can choose to use a
fixed font to view its benefits or a proportional font if the reader
thinks that natural (i.e. like a book) text and screen real estate are
more important.  If a writer chooses no alignment, the reader can
still use fixed fonts if that provides maximal confort, and given
syntax highlighting, should still find the code quite readable.
- No arbitrary line length, although a writer could certainly
self-impose one.

Regarding the line termination issue, I like the idea of the boost
library handling all line terminators in a common way.  Unlike other
formatting issues, tradeoffs for line terminators aren't based on the
nature of the program or thinking patterns of the author, but rather
just the platform on which the file is used.  Since the files are all
platform independent, there isn't any reason from a library usage
standandpoint to have variation between files.  The variations only
come based on the development platform, which should be transparent to
downloaders.  How easy would it be to run a filter over the boost
library before publishing updates to convert all the line terminators
to a single style? As far as what style, since this is a C++ library,
I say follow the C++ convention and use \n; i.e. LF only.

> > I have to make a pairing heap for school and use it implement
> > the single source, shortest path algorithm.  My long-term goal,
> > though is to have the pairing heap be a
> > priority queue with an interface just like std::priority_queue,
> > except with erase, merge, and increase methods.
>
> I assume you have looked at
> http://www.boost.org/libs/pri_queue/heap.html

Yes, but such a long time ago that I had totally forgotten about it.
(That was before I really understood what a heap was in the priority
queue sense). Thanks for the reminder. It is nice now looking at the
interfaces and really understanding what is going on. I shouldn't look
at the implementation until I turn in my homework, though. The scope
of the heap library looks like all of what I had in mind plus more,
which as it is may provide a good playground for experimenting with a
capability model.