[description of the problem of refactoring and code consistency in lilpond libs - snipped ]
> So in essence what we need is a convert-ly-like tool for openLilyLib, > either as an independent tool or by somehow hooking into convert-ly > itself. Quite some time ago I opened an issue about this and would now > like to get some opinions, ideas and experiences how *you* deal with the > topic. > > Please reply here or add to > https://github.com/openlilylib/openlilylib/issues/87. In software development this is a well known problem and AFAIA there does not exists a solution to this problem in total. However there are quite a few guidelines to help reducing the issues that may arise. Among them are: - modularisation: whatever sequence of commands is used regularly in various files should be moved into a function/macro. That way any adjustment needs to be done just once and in one place only. - external (from the perspective of a LP installation) functions that are likely to change should be encapsulated in a wrapper function. Again the benefit is that adjustments need to be done just once. - one might wish for function prototypes and/or function signatures in lilypond such that the compiler/parser could better flag illegal use of functions and/or macros. At least for me the current error diagnostics do not always point me to the cause of the error. It sometimes takes me quite some time to understand what actually went wrong (but that may be just me - more experienced lilyponder might have a different mileage) Kind regards, Michael -- Michael Gerdau email: m...@qata.de GPG-keys available on request or at public keyserver
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
