lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coding practices


From: Han-Wen Nienhuys
Subject: Re: Coding practices
Date: Sat, 16 Feb 2013 17:00:49 +0100

On Sat, Feb 16, 2013 at 3:15 PM, address@hidden
<address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]