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

From: Christian LE BARS <[email-masked]>
Date: Mon, 11 Feb 2019 09:35:50 +0100

bonjour a tous.

Voila j'ai programmé pendant une quinzaine d'année, dans une entreprise.
(il y a longtemps)

Et la production logicielle nous obligeait à produire un code avec
toujours les mêmes règles de présentation.

Le programme principal se trouvait toujours en fin de listing.

chaque fonction écrite ne traitait que d'un seul sujet et n’excédait pas
une page.

chaque fonction,  avait une entête dans laquelle on trouvait une phrase
courte de description.

le libellé des variable utilisée. les différentes modifications datées,
apportées .

Si j'applique les règles au code Lilypond voila ce que cela donne:

je prends  pour exemple le code de Valentin (qui est tout bon, je
travaille sur la forme pas le contenu)

accords = \chordmode {
  d1:m6 f:m e:m9
}

mélodie = \relative c' {
  a'4_( b a' b)
  g,_( as g' as)
  fis,_( g fis'2)
}

\score {
  \header { piece = "Solo" }
  <<
    \new ChordNames \accords
    \new Staff \mélodie
}

\score {
  \header { piece = "Piano" }
  <<
    \new Staff \mélodie
    \new PianoStaff <<
      \new Staff \relative c' {
        <b f' a>1 <c f as> <b d fis g>
      }
      \new ChordNames \accords
      \new Staff \relative c {
        \clef bass
        d1 f2 c e,1
      }
}
Maintenant j'applique les règles que l'on m'a apprisent

accords = 
\chordmode 
{
  d1:m6 f:m e:m9
}
%---------------------------------------------
mélodie = 
\relative c' 
 {
  a'4_( b a' b)
  g,_( as g' as)
  fis,_( g fis'2)
 }
%---------------------------------------
\score
{
  \header { piece = "Solo" }
  <<
    \new ChordNames \accords
    \new Staff \mélodie
}
%------------------------------------------
\score
 {
  \header { piece = "Piano" }
  <<
    \new Staff 
     \mélodie
    \new PianoStaff 
     <<
      \new Staff
       \relative c' {<b f' a>1 <c f as> <b d fis g> }
      \new ChordNames 
       \accords
      \new Staff 
       \relative c 
       {
        \clef bass
        d1 f2 c e,1
       }
}
une accolade qui s'ouvre
doit toujours avoir son accolade fermante au même niveau 

Voila ce que j'ai appris. Mais peut être que cela est hors sujet.
c'est un détail, et ce forum est vraiment performant. 
J'ai toujours eu de bonne réponse.
et merci à ceux qui accepte de répondre 
Cordialement 
Christian

---

From: Éditions IN NOMINE <[email-masked]>
Date: Mon, 11 Feb 2019 09:46:46 +0100

Bonjour à tous,

Je pense que ce n'est pas hors sujet du tout. Même si, parlant de
logiciel de gravure, la sensibilité première attendue n'est pas
forcément celle de la beauté du code :-)

J'approuve totalement ton propos. La "beauté" du code n'est pas une
lubie de geek gavé de pizza et de coca ; c'est un outil puissant qui
permet :

1. de maintenir aisément son code (notamment un fichier definitions.ly
qui devient vite une vraie jungle de milliers de lignes) et de se relire
aisément

2. de partager son code avec la certitude d'être compris

Pour celles et ceux qui pratiquent Frescobaldi, cet outil permet de
respecter peu ou prou les régles de base, ce qui est bien pratique !

La doc parlant de l'organisation du code
(http://lilypond.org/doc/v2.19/Documentation/notation/file-structure)
est à mon sens très bien faite, mais, tout en proposant des exemples de
code "propres", ne fait pas l'apologie de cette pratique (à ma
connaissance, les exemples de codes dans toute la doc respectent les
principes évoqués par Christian) : ce serait pas mal de suggérer ces
bonnes pratiques dans un paragraphe de ce chapitre ? Libre à chacun de
s'y référer ou pas, bien évidemment.

Amitiés !

JMarc

Le 11/02/2019 à 09:35, Christian LE BARS a écrit :
> _______________________________________________
> liste de diffusion lilypond-user-fr
> [email-masked]
> https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

---

From: Olivier Albiez <[email-masked]>
Date: Mon, 11 Feb 2019 10:25:25 +0100

Bonjour,

Je suis développeur et je forme des développeurs. La forme d'un code source
est pour moi importante dans la transmission des intentions.

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.

Bien sincèrement.

Le lun. 11 févr. 2019 à 09:36, Christian LE BARS <[email-masked]> a

---

From: Valentin Villenave <[email-masked]>
Date: Mon, 11 Feb 2019 09:58:06 +0000

> 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.

---

From: gerardk <[email-masked]>
Date: Mon, 11 Feb 2019 02:59:33 -0700 (MST)

Bonjour,

Je partage tous les avis sur la facilité apportée par un code propre, c'est
mon expérience de 30 ans d'informatique qui me permet de le dire. J'ai aussi
saisi "quelques" partitions sous Lilypond et les principes de programmation
se sont révélés efficaces.
J'irai un tout petit peu plus loin dans la rigueur du code, c'est dans la
présentation des notes. je présente mon code comme ceci :
      \relative c'
      {
        *1 |
        <c f as> |
        * |
      }
Pour moi, toute parenthèse ouvrante doit avoir une parenthèse fermante au
même aplomb (contrairement à la mode de certains outils de programmation
actuellement).
Je mets une mesure par ligne et j'utilise les "|" pour contrôler le bon
remplissage des mesures.

Je ne peux qu'encourager la diffusion de ces pratiques.

--
Sent from: http://lilypond-french-users.1298960.n2.nabble.com/

---

From: Valentin Villenave <[email-masked]>
Date: Mon, 11 Feb 2019 10:44:38 +0000

> Je mets une mesure par ligne et j'utilise les "|" pour contrôler le bon

Ah, les contrôle de mesure… Ça aussi c’est une question de goût (de
même que la langue employée pour le nom des notes, entre les "rapides"
qui préférent une seule lettre par note, et les "chantants" qui
préfèrent des notes formant des syllabes).

C’est vrai que les contrôles de mesure sont recommandés dans la doc ;
pour ma part je les ai beaucoup utilisé autrefois, puis j’ai cessé de
les mettre à chaque mesure pour ne les mettre qu’à la fin de chaque
ligne de code (une ligne pouvant regrouper plusieurs mesures lorsqu’il
n’y a pas beaucoup de notes)… puis j’ai fini par cesser complètement
de les utiliser, ce qui me fait gagner un temps considérable. (Mais ce
n’est pas une pratique que je recommanderais à d’autres.)

Une autre bonne habitude à prendre, qui a récemment été mentionnée sur
la liste anglophone et à laquelle je n’avais jamais pensé, est de ne
jamais commencer une ligne par une durée implicite : plutôt que

\relative c' {
  c2 d4 e
  f g a b
  c1
}

Préférez ceci :

\relative c' {
  c2 d4 e
  f4 g a b
  c1
}

De cette façon, si vous avez besoin de citer ou copier une ligne hors
de son contexte, ou que vous changez d’avis dans une composition et
décidez de supprimer quelques lignes, cela posera moins de problèmes
de raccord.

(Encore un excellent conseil… que je ne suis pas personnellement :-)

V.

---

From: gerardk <[email-masked]>
Date: Mon, 11 Feb 2019 03:51:22 -0700 (MST)

Pour le nom des notes, je serai moins catégorique étant donné qu'on peut
facilement changer la langue. Ce n'est pas comme la position des accolades
ou la présente des barres de mesure de contrôle qu'on ne peut ps facilement
ajouter ou modifier. La langue des notes est plus une question d'habitude
que de bonne pratique.

---

From: Aiki Zen <[email-masked]>
Date: Mon, 11 Feb 2019 12:33:32 +0100

> le libellé des variable utilisée. les différentes modifications
bonjour,

puisque qu'on est dans la présentation du code, j'ai essayé de suivre
vos conseils. cela donne ça :

\version "2.18.2"

up = \upbow do = \downbow

musique = \relative c 
    {

    c8\do\5 d\up\5 e\do\5 f\up\4 g\do\4 a\up\4 b\do\3 c\up\3
     d\do\3 e\up\2 f\do\2 g\up\2 a\do\1 b\up\1 c\do\1 b\up\1
     a\do\1 g\up\2 f\do\2 e\up\2 d\do\3 c\up\3 b\do\3 a\up\4
     g\do\4 f\up\4 e\do\5 d\up\5 c2\do\5

    }
%------------------------------------------------------
\score
    {
        << \new Staff
        {
            \clef "treble_8"
            \omit Voice.StringNumber
            \musique
        }
            \new TabStaff
        {
            \musique
        } >>
\layout {}
     }

qu'en pensé vous ? qui à t'il à modifier ?

en passant comment alligner les \upbow et /downbow sur une même ligne
pour une meilleur lecture ?

cordialement,
aiki.

---

From: Christophe Pochon <[email-masked]>
Date: Mon, 11 Feb 2019 13:08:13 +0100

Une solution (même si ce n'est pas dans ce sujet que tu aurais dû poser
cette question) :

%%%%%%%
\version "2.18.2"

up = \upbow do = \downbow
dyn = { \repeat unfold 14 {s8\do s8\up} s2\do }
musique = \relative c
    {

    c8\5 d\5 e\5 f\4 g\4 a\4 b\3 c\3
     d\3 e\2 f\2 g\2 a\1 b\1 c\1 b\1
     a\1 g\2 f\2 e\2 d\3 c\3 b\3 a\4
     g\4 f\4 e\5 d\5 c2\5

    }
            \new Dynamics \dyn
            \new Staff
        {
            \clef "treble_8"
            \omit Voice.StringNumber
            \musique
        }
            \new TabStaff
        {
            \musique
        } >>
\layout {}
     }
%%%%%%%%%%%%%%

Christophe Pochon

---

From: Philippe Neyrat <[email-masked]>
Date: Mon, 11 Feb 2019 19:13:55 +0100

Salut !

Pour ma part, et c'est sans doute un vieux reste de C/C++, je ne laisse 
pas la parenthèse ouvrante après la fonction, je la mets en premier à la 
ligne suivante, et je ne l'indente pas.

\relative c'
{
   Bla
}

Et j'indente avec deux caractères, je n'utilise pas de tabulation.
;-)

Frescobaldi m'aide beaucoup pour visualiser les imbrications, qui 
peuvent parfois être assez profondes, et aussi permet l'indentation 
automatique, ce qui est un confort de plus.

Et comme j'ai déjà dit, je commente, je mets une mesure par ligne, des 
contrôles de mesure, etc...

Philippe

-- 
Propulsé par l'Association Sud-Ouest.org
Plateforme Libre d'hébergement mail à prix libre
     https://www.sud-ouest.org

---

From: Olivier Miakinen <[email-masked]>
Date: Mon, 11 Feb 2019 23:06:14 +0100

Bonjour,

Le 11/02/2019 10:58, Valentin Villenave a écrit :
> [...] oui j’ai remarqué
> leurs accolades sur une nouvelle ligne, comme en C++ ;

Comme *l'une* des pratiques de C ou C++. Il y en a plusieurs, et
pour ma part je programme en C/C++ comme toi (et moi) en LilyPond.

> la pratique la

Oui.

> #(define-music-function (m) (ly:music?)

Eh bien moi j'utilise exactement la même méthode en LISP qu'en C, donc
je ferais ceci en Scheme :

blabla=
    )
  )
)

Ma règle est que chaque parenthèse fermante est :
- soit sur la même ligne que la parenthèse ouvrante ;
- soit sur une ligne ayant exactement la même indentation
  que la ligne de la parenthèse ouvrante.
Exactement la même règle que les accolades en C ou en LilyPond.

Donc, cela peut être aussi :

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

Ou bien :

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

Ou encore :

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

Je trouve ça beaucoup plus lisible que ces fonctions qui se terminent
par un zillion de parenthèses fermantes à droite de la dernière ligne
de code.

> [...]>
> seule ligne, par exemple \tuplet {} ;

Tout pareil, sauf si la ligne est elle-même trop longue (généralement
je ne dépasse pas 80 caractères par ligne, voire 72 comme dans les
courriels). Mais je fais la même chose en C, C++, PHP, HTML, LilyPond,
LISP, Java, etc. : je peux mettre le « bidule » fermant sur la même
ligne que le « bidule » ouvrant (quel que soit le « bidule ») si toute
la ligne est assez courte, sinon les « bidules » ouvrant et fermant
seront sur deux lignes ayant la même indentation.

> de plus j’évite systématiquement

Bon, là j'avoue que c'est variable. Il m'arrive de mettre des accolades
inutiles, de même que dans une expression en C il m'arrive de mettre des
parenthèses inutiles, pour faciliter la lecture de ceux qui sont peu à
l'aise avec la priorité des opérateurs.

> [...]

Oui (et oui).

-- 
Olivier Miakinen

---

From: Monteverdi <[email-masked]>
Date: Thu, 14 Feb 2019 08:44:13 -0700 (MST)

Moi, je suis pour l'ordre.

J'aime que les voyous soient d'un côté et les poulagas de l'autre. Et votre
pote, on ne savait plus très bien de quel côté il était. À force de
fréquenter le milieu, il s'y était fait des relations. Même, en quelque
sorte, de la famille.

("Le Pacha", d'André Weber (1968) avec Jean Gabin, dialogues de Michel
Audiard)