On Sat, Feb 16, 2013 at 3:15 PM, m...@mikesolomon.org <m...@mikesolomon.org> wrote: >>>> Rather than letting this continue to be problematic, I'd like to >>>> establish a sort of GLISS for LilyPond coding style. We would discuss >>>> certain conventions in the codebase to see where commonalities lie in >>>> the codebase and where things could be made to look more similar. >>> >>> That's the wrong approach for coding guidelines since it assumes that >>> "commonalities in the code base" suggest a reasonable coding practice. >>> >>> The vast majority of the LilyPond code base is not coded with >>> maintainability or transparency to third-party programmers in mind.
To give some context: a large portion of the code base was coded to try to solve a very poorly specified problem, without knowing in advance how long said code was to survive. Some parts have aged pretty well (property caching, beam/slur scoring), but others less so (part combining comes to mind, for example). >>> If you want an example of reasonable documenting and coding practice, >>> take tex.web (it is public domain), run it through weave and pdftex and >>> peruse significant extracts of the resulting PDF. >> >> While tex.web is a beautiful example of literate programming, it was >> >> a. created by one the worlds' foremost computer scientists. >> b. created for a program whose behavior and code was to be set in stone. >> >> I think that looking at tex.web will not give anyone practical answers >> on how to structure their lilypond code. >> > > I've heard from friends that Google has codified standards for how code > should be written. What are these standards like? Is this the type of thing > that could be implemented for LilyPond programming? Yes. Some of it is even open source. See http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml. It is a matter of taking an arbitrary decision and doing the thankless job of bringing the code base into conformance. It's also a topic that easily generates a lot of discussion (bikeshedding) where each opinion is equally good, objectively speaking. (Since code formatting is such a distraction, Google people have actually written a new code C++ formatter so people don't have to waste time on discussing those; see http://clang.llvm.org/docs/ClangFormat.html) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
