>> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
