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

[Olivier Miakinen]

Bonjour,

Le 11/02/2019 10:58, Valentin Villenave a écrit :
> 
> [...] oui j’ai remarqué
> que quelques utilisateurs (notamment Christian) préféraient ouvrir
> 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
> 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
> }

Oui.

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

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

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

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.

> [...]>
> 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 {} ;

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
> de mettre des accolades dans des expressions à un seul argument,
> telles que
> \markup \bold \italic "bla"
> ou
> \repeat unfold 256 b16

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.

> [...]
> 
> 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 :-)

Oui (et oui).

-- 
Olivier Miakinen