Re: présentation du code (je me mêle de ce qui me regarde pas)

[Valentin Villenave]

On 2/11/19, Olivier Albiez <address@hidden> wrote:
> J'y vois en plus une analogie entre la précision de la gravure d'une
> partition qui est à destination du musicien et la précision de son code
> source à l'intention des "mainteneur" de la partition.

J’avais il y a quelques années proposé un travail de recherche
universitaire portant précisément sur le style de codage en tant
qu’objet expressif, sous un point de vue sémiologique/linguistique.
LilyPond, effectivement, se situe à la frontière entre un langage
expressif (la musique) et un langage utilitariste (produire du code
qui parvienne à être compilé par le programme, et compris et maintenu
par d’autres humains). Par exemple, la façon dont le code est
structuré et commenté, le choix des variables et leurs noms etc., peut
donner des informations parfois intéressantes d’un point de vue
musical.

Et nous sommes de ce point de vue dans une situation assez unique et
privilégiée ; le code LilyPond est beaucoup plus destiné à être écrit
et lu directement qu’aucun autre langage de haut niveau actuellement
répandu ; en musique c’est évident (il suffit de lire trois lignes de
MusicXML pour s’en convaincre) mais même dans les autres domaines :
- LaTeX est en général saisi au kilomètre et de façon assez sale par
les scientifiques ; même un romancier ou un poète qui travaillerait en
LaTeX (il y en a eu quelques-uns) n’a en général pas énormément
d’égards pour l’expressivité de son style de codage ;
- Les langages de balisage élémentaire (MarkDown, BBcode, SPIP) ou
avancé (WikiCode) sont rarement lus en tant que tels ; même Wikipédia
s’emploie depuis quelques années à cacher honteusement son code
derrière une interface Wysiwyg lamentable ;
- PostScript est de moins en moins saisi à la main de nos jours ; les
langages de type HTML/XML/SVG etc. sont souvent écrits et lus par des
humains mais n’ont ni la concision ni l’élégance du code LilyPond ;
- le seul équivalent que je verrais est éventuellement POV-Ray… mais
on parle ici d’un langage extrêmement spécialisé, voire de niche.
(LilyPond a d’ailleurs une lointaine origine en TeX, mais surtout des
influences en PostScript et même en POV-Ray.)

Après ce petit préambule plus ou moins hors sujet, oui j’ai remarqué
que quelques utilisateurs (notamment Christian) préféraient ouvrir
leurs accolades sur une nouvelle ligne, comme en C++ ; la pratique la
plus répandue chez les LilyPondeurs (et celle que nous utilisons dans
la doc) est plutôt d’ouvrir l’accolade à la suite de la commande qui
la gouverne, comme en TeX. C’est ma propre préférence, probablement
parce que je n’ai découvert le C++ qu’après (et à cause de) LilyPond.
À tel point que je n’aime pas du tout commencer une ligne par une
accolade ; c’est pourquoi je vais ainsi écrire

\new Staff \with {
  [blablabla]
} {
  [ma musique
}

Cependant, autant on aime bien qu’une accolade fermante se retrouve
toute seule sur une ligne (avec le niveau d’indentation qui va bien),
autant dès qu’on arrive en Scheme c’est complètement différent :

blabla=
#(define-music-function (m) (ly:music?)
  (make-sequential-music
    (list
     (ly:music-deep-copy m)
     (ly:music-deep-copy m))))

Ou éventuellement :

blabla=
#(define-music-function (m) (ly:music?)
  (make-sequential-music
    (list
     (ly:music-deep-copy m)
     (ly:music-deep-copy m))
    ))

_Mais_ si on se met à inclure de la syntaxe Lily dans le Scheme, c’est
reparti en style Lily :

blabla=
#(define-music-function (m) (ly:music?)
   #{
     #m #m
   #})

Après, il y a aussi des questions de style personnel ; par exemple
personnellement je n’aime pas revenir à la ligne dans un bloc d’une
seule ligne, par exemple \tuplet {} ; de plus j’évite systématiquement
de mettre des accolades dans des expressions à un seul argument,
telles que
\markup \bold \italic "bla"
ou
\repeat unfold 256 b16

ou encore

<<
  \new Staff \relative c' { e }
  \new Staff \relative c' { c }
>>

là où d’autres (et la doc) feraient, par exemple :

\score {
  <<
    \new Staff {
      \new Voice {
        \relative c' {
          e
        }
      }
    }
    \new Staff {
      \new Voice {
        \relative c' {
          c
        }
      }
    }
  >>
  \layout { }
}

Bref, c’est une question de goût, chacun a son style, le tout est de
l’appliquer d’une façon cohérente (et ne parlons même pas de
tab-vs-space pour ne pas fâcher :-)

V.