Re: Thoughts on doxygen for internal documentation

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <200301161803.h0GI3DYV018983@mururoa.inria.fr> you write:
>As an example, I always wondered why the rule of 80 columns is still
>that strict. IMHO often code can be more readable using longer lines
>(still with a reasonnable limit, just an higher one).  Yes I know, some
>people still have a very old 80 columns VT100, but those cannot be 
>that many ? Indeed, mail reader sometimes have this 80 limit constraints,
>but then problems with line wrapping by mailers happen also with 80 
>columns... So why keeping this constraints and not updating it to 
>something more sensible such as eg 132 colums.

80 columns still has lots of advantages. with 80 columns lines, I can
put two xterms of a readable font size side by side on my laptop.
Not so with 132 columns.

I think that 80 columns keep programmers honest. When you find out
that your code is consistently flushed against the right border, it's
probably because the nesting of your code is too deep to make sense.

But, hey, of course, the gnu coding standards, at least the formatting
part, make no sense to a large proportion of the coding community
anyways (the linux kernel, and the bsd code being two prime examples
of code that does not follow those conventions) :)