Re: Code formatter

[demery]

>> 2) many programmers view code style in a highly personal,
>> quasi-religious manner.
> ...
>> ...Han-Wen and Jan have different views...

Foe me its a matter of blocking the whitespace to to present the code in a
way that makes it easier to understand.  This is not easy to do with any
automated tool.

A project done by a one-man team sees a limited set of tools and has a
limited amount of schizophrenia in esthetic decisions.

When the product is ported to as many platforms as ly is you see all the
toolsets and more.  Fonts make a difference.  Screen size and eyestrain
influence choice of font and font size.  Vendor coding style influences
things too.  Apple used to be rather cavalier about code namespace, they
would use short common words for class, structure, and field symbols. 
With cocoa things are somewhat improved, NS prefixes everything new, and
method names are verbose and attempt to be meaningful.  The verbosity has
a downside tho, many invocations are multi-line, especially when localized
text is involved.

> If the standard isn't even completely defined then how could the job of
> code janitor be given to an inexperienced Frog?

Actually, its a pretty good learning experience.

> until an official LilyPond coding standard is
> fully set in stone.

IMHO that would be a mistake, for example, switch statements have a number
of ways of being presented that are effective, no one way serves all code.

>> Any automatic tool will

have faults, including being unavailable on some platform now in use.

I recall a movement sometime ago to mix code and prose commentary, making
real tab stops available for the code, and also allowing illustrations. 
Guess it died a hard death.

--
Dana Emery