[SPIP Zone] Règles des bonnes écriture : les accolades pour les conditions

Archives Zone
1

Le problème se situe dans les cas des conditions simples.

Voici un extrait de configurer.php :
if ($arg == ‹ relayeur ›)
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],"&");
else if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
if (_request(‹ envoi_now ›)) cron(0, array(‹ mail › => -1));

L’absence de parenthèses entraine une ambiguïté lors de la lecture rapide : ici par exemple il n’est pas immédiat que la fontion calculer_langues_rubriques() n’est appelée que si $arg vaut ‹ langue ›. C’est aussi dû à l’indentation qui place le bloc au même niveau que le précédent.

Le ‹ if › suivi d’une fonction sans accolade autour, c’est par expérience souvent plantogène.

Je propose qu’on recommande de toujours mettre les accolades pour le bloc qui suit une condition ou une boucle
(avec espace, retour à la ligne et indentation du contenu par une tabulation)

Le code souhaitable serait alors le suivant :
if ($arg == ‹ relayeur ›) {
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],"&");
}else {
if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
}
if (_request(‹ envoi_now ›)) {
cron(0, array(‹ mail › => -1));
}

Qu’en dites-vous ?

2

Le 6 mai 2010 à 23:42, Gilles VINCENT a écrit :

Le problème se situe dans les cas des conditions simples.

Voici un extrait de configurer.php :
if ($arg == ‹ relayeur ›)
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
else if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
if (_request(‹ envoi_now ›)) cron(0, array(‹ mail › => -1));

L’absence de parenthèses entraine une ambiguïté lors de la lecture rapide : ici par exemple il n’est pas immédiat que la fontion calculer_langues_rubriques() n’est appelée que si $arg vaut ‹ langue ›. C’est aussi dû à l’indentation qui place le bloc au même niveau que le précédent.

je vois pas la non immediateté. Ça semble couler de source
if …
elseif {
…
}

l’indentation montre clairement que l’on est dans le elseif

Le ‹ if › suivi d’une fonction sans accolade autour, c’est par expérience souvent plantogène.

bof, moi je trouve ça lourd de mettre des accolades pour une ligne

Je propose qu’on recommande de toujours mettre les accolades pour le bloc qui suit une condition ou une boucle
(avec espace, retour à la ligne et indentation du contenu par une tabulation)

Le code souhaitable serait alors le suivant :
if ($arg == ‹ relayeur ›) {
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
}else {
if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
}
if (_request(‹ envoi_now ›)) {
cron(0, array(‹ mail › => -1));
}

Qu’en dites-vous ?

bof

Cédric

3

Mon exemple était mal choisi : il vaut mieux utiliser
if () {} elseif () {}

plutôt que la construction
if () {} else {if () {}}

Car d’un point de vue lecture, l’excès d’accolades devient vite pénible.

Mais lorsqu’il n’y a qu’une instruction après le if(), il y a parfois des accolades, parfois pas.
Je pense qu’il faudrait conseiller d’utiliser la première écriture.

2010/5/7 cedric.morin@yterium.com <cedric.morin@yterium.com>

Le 6 mai 2010 à 23:42, Gilles VINCENT a écrit :

Le problème se situe dans les cas des conditions simples.

Voici un extrait de configurer.php :
if ($arg == ‹ relayeur ›)
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
else if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
if (_request(‹ envoi_now ›)) cron(0, array(‹ mail › => -1));

L’absence de parenthèses entraine une ambiguïté lors de la lecture rapide : ici par exemple il n’est pas immédiat que la fontion calculer_langues_rubriques() n’est appelée que si $arg vaut ‹ langue ›. C’est aussi dû à l’indentation qui place le bloc au même niveau que le précédent.

je vois pas la non immediateté. Ça semble couler de source
if …
elseif {
…
}

l’indentation montre clairement que l’on est dans le elseif

Le ‹ if › suivi d’une fonction sans accolade autour, c’est par expérience souvent plantogène.

bof, moi je trouve ça lourd de mettre des accolades pour une ligne

Je propose qu’on recommande de toujours mettre les accolades pour le bloc qui suit une condition ou une boucle
(avec espace, retour à la ligne et indentation du contenu par une tabulation)

Le code souhaitable serait alors le suivant :
if ($arg == ‹ relayeur ›) {
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
}else {
if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
}
if (_request(‹ envoi_now ›)) {
cron(0, array(‹ mail › => -1));
}

Qu’en dites-vous ?

bof

Cédric

4

6 May 2010, Gilles:

if ($arg == 'relayeur')
     $r = parametre_url($r, 'retour_proxy',
$GLOBALS['retour_proxy'],"&"); else if ($arg == 'langue') {
     include_spip('inc/rubriques');
     calculer_langues_rubriques();
}
if (_request('envoi_now')) cron(0, array('mail' => -1));

L'absence de parenthèses entraine une ambiguïté lors de la lecture
rapide : ici par exemple il n'est pas immédiat que la fontion
calculer_langues_rubriques() n'est appelée que si $arg vaut 'langue'.

En théorie, on est d'accord:
if (A) {
    #a
} else {
    if (B) {
        #b
    } else {
        if (C) {
            #c
        } // finC
    } // finB
} // finA

Car PHP ne possède pas le "elseif" qu'on trouve dans d'autres langages.

Le truc, c'est que du coup, ça devient vite lourd à lire, comme le
souligne Cédric. Fonctionnellement, dans ce cas précis (très
exactement: else avec pour seule instruction un if), je crois que c'est
assez safe d'accepter le "else if" comme si c'était un seul mot-clé
malgré l'espace "dedans", et donc de le laisser se comporter comme un
else, à l'instar du elseif des autres langages.

if (A) {
    #a
} else if (B) {
    #b
} else if (C) {
    #c
} // finC, donc finB car fin du 2e else, donc finA car fin du 1er else

En effet, si on a un else avec pour seule instruction un if, la fin du
if implique la fin du else précédent, donc on peut considérer la paire
else-if ensemble.

Le 'if' suivi d'une fonction sans accolade autour, c'est par
expérience souvent plantogène.

Dans tous les autres cas que celui cité, méga-d'accord: c'est la super
peau de banane, donc à éviter.

Exemple :

if (A)
    truc();
chose();
$machin = $toto + 42;
// etc.

Un jour on rajoute une instruction :

if (A)
    spip_log("On va faire truc()");
    truc();
chose();
$machin = $toto + 42;
// etc.

Et là, paf, on passe 2h à débugguer. Dans cet exemple, le piège est
immédiat, mais dans du vrai code qui tache avec des grosses conditions
de derrière les fagots et pas juste "A", c'est pas si évident. Autant
perdre une ligne avec une accolade fermante (l'accolade ouvrante étant
de toute façon sur la ligne du if).

Je propose qu'on recommande de toujours mettre les accolades pour le
bloc qui suit une condition ou une boucle
(avec espace, retour à la ligne et indentation du contenu par une
tabulation)

Oui, avec l'exception du "else if", donc.

--
davux

5

7 May 2010, davux:

Car PHP ne possède pas le "elseif" qu'on trouve dans d'autres
langages.

Bigre, mais en fait si.
Alors je maintiens quand même mon raisonnement précédent (autoriser
exceptionnellement "else if" sans accolades), avec la nuance que quand
même, tant qu'à faire, autant utiliser elseif, comme le dit Gilles,
comme ça la question ne se pose même pas.

--
davux

6

Le 7 mai 2010 05:42, Gilles VINCENT <gilles.vincent@gmail.com> a écrit :

Le problème se situe dans les cas des conditions simples.

Voici un extrait de configurer.php :
if ($arg == ‹ relayeur ›)
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
else if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
if (_request(‹ envoi_now ›)) cron(0, array(‹ mail › => -1));

L’absence de parenthèses entraine une ambiguïté lors de la lecture rapide : ici par exemple il n’est pas immédiat que la fontion calculer_langues_rubriques() n’est appelée que si $arg vaut ‹ langue ›. C’est aussi dû à l’indentation qui place le bloc au même niveau que le précédent.

Le ‹ if › suivi d’une fonction sans accolade autour, c’est par expérience souvent plantogène.

Je propose qu’on recommande de toujours mettre les accolades pour le bloc qui suit une condition ou une boucle
(avec espace, retour à la ligne et indentation du contenu par une tabulation)

Le code souhaitable serait alors le suivant :
if ($arg == ‹ relayeur ›) {
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
}else {
if ($arg == ‹ langue ›) {
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
}
if (_request(‹ envoi_now ›)) {
cron(0, array(‹ mail › => -1));
}

Qu’en dites-vous ?

Personellement, j’utilise plutôt cette indentation :

if ($arg == ‹ relayeur ›)
$r = parametre_url($r, ‹ retour_proxy ›, $GLOBALS[‹ retour_proxy ›],« & »);
else if ($arg == ‹ langue ›)
{
include_spip(‹ inc/rubriques ›);
calculer_langues_rubriques();
}
if (_request(‹ envoi_now ›)) cron(0, array(‹ mail › => -1));

Je n’ai jamais compris pourquoi autant de gens y est allergique.

7

Le 07/05/2010 02:25, simon camerlo a écrit :

    Le problème se situe dans les cas des conditions simples.

    Voici un extrait de configurer.php :
      if ($arg == 'relayeur')
          $r = parametre_url($r, 'retour_proxy',
    $GLOBALS['retour_proxy'],"&");
      else if ($arg == 'langue') {
          include_spip('inc/rubriques');
          calculer_langues_rubriques();
      }
      if (_request('envoi_now')) cron(0, array('mail' => -1));

    L'absence de parenthèses entraine une ambiguïté lors de la lecture
    rapide : ici par exemple il n'est pas immédiat que la fontion
    calculer_langues_rubriques() n'est appelée que si $arg vaut
    'langue'. C'est aussi dû à l'indentation qui place le bloc au même
    niveau que le précédent.

Je ne vois pas quelle est l'ambiguité car il y a là une indentation
qui indique clairement l'imbrication, même lors d'une lecture rapide.
...

    Le 'if' suivi d'une fonction sans accolade autour, c'est par
    expérience souvent plantogène.

    Je propose qu'on recommande de toujours mettre les accolades pour le
    bloc qui suit une condition ou une boucle
    (avec espace, retour à la ligne et indentation du contenu par une
    tabulation)

    Le code souhaitable serait alors le suivant :
      if ($arg == 'relayeur') {
          $r = parametre_url($r, 'retour_proxy',
    $GLOBALS['retour_proxy'],"&");
    }else {
          if ($arg == 'langue') {
              include_spip('inc/rubriques');
              calculer_langues_rubriques();
          }
    }
      if (_request('envoi_now')) {
          cron(0, array('mail' => -1));
      }

    Qu'en dites-vous ?

Personellement, j'utilise plutôt cette indentation :

if ($arg == 'relayeur')
      $r = parametre_url($r, 'retour_proxy', $GLOBALS['retour_proxy'],"&");
else if ($arg == 'langue')
{
      include_spip('inc/rubriques');
      calculer_langues_rubriques();
}
if (_request('envoi_now')) cron(0, array('mail' => -1));

Je n'ai jamais compris pourquoi autant de gens y est allergique.

C'est clair que c'est clair,
mais c'est un peu "scolaire" et lourd (PASCAL vs C)
et ça étale-dilue le code "pour rien".

JLuc

8

S'lt

Hum je crois que l'exemple proposé est encore mal choisi car
switch/case est tres bien, plus leger que ces elseif

Pour la question de fond, comme php ne comprend rien à l'indentention,
il semble logique de preferer les { } meme pour une ligne de
traitement (bien que parfois c'est bien lourd et usant à rédiger).
Cela permet d'avoir toujours la meme écriture, de réduire ses
exceptions, donc augmente l'aisance de relecture.

Je note toutefois une exception le $toto = $titi ? $x : $y; sur une ligne

De meme, je prefere l'écriture européen :
if () {
#bla
}
que l'anglosaxone
if ()
{
#bla
}

Et enfin l'indentention souvent c'est une tabulation de 4 espaces.

Mes 2 sous

9

2010/5/7 cam.lafit@azerttyu.net <cam.lafit@azerttyu.net>

S’lt

Hum je crois que l’exemple proposé est encore mal choisi car
switch/case est tres bien, plus leger que ces elseif

Pour la question de fond, comme php ne comprend rien à l’indentention,
il semble logique de preferer les { } meme pour une ligne de
traitement (bien que parfois c’est bien lourd et usant à rédiger).
Cela permet d’avoir toujours la meme écriture, de réduire ses
exceptions, donc augmente l’aisance de relecture.

Je note toutefois une exception le $toto = $titi ? $x : $y; sur une ligne

Tiens, c’est bien ton exemple car tu l’écris avec des espaces.
Dans les différents codes que j’ai lu, c’était pas toujours le cas.
J’ai remarqué que lorsque l’écriture est vraiment courte, les espace disparaissent, et ce d’autant plus si cette expression est enchainée avec une autre.

Exemple :
$chaine = « Vous avec « .$n. » résultat ».($n>1?‹ s ›:‹  ›)." à votre requête";

J’avoue que je n’aime pas trop ces formes ratatinées, même si elles permettent de mieux percevoir l’unité logique de ($n>1?‹ s ›:‹  ›). [et encore, cet exemple est trivial, mais plus l’expression devient complexe, genre avec des affectations dans des if(), moins l’ensemble est lisible]

Ce manque de lisibilité n’est-il pas aussi lié aux concaténations de chaines qui n’utilise pas d’espace ?

De meme, je prefere l’écriture européen :
if () {
#bla
}
que l’anglosaxone
if ()
{
#bla
}

idem.

Et enfin l’indentention souvent c’est une tabulation de 4 espaces.

Perso je préfère la liberté offerte par la tabulation en début de ligne :
en effet mon IDE est réglé à 8caractères pour une tabulation, j’aime bien prendre de l’espace :slight_smile:

Plus prosaïquement, les tabulations sont déjà utilisées presque partout, donc à mon avis c’est devenu une règle « d’usage »

Mes 2 sous

et je rajoute un kopek :wink:

.Gilles

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

10

Gilles VINCENT a écrit :

De meme, je prefere l’écriture européen :
if () {
#bla
}
que l’anglosaxone
if ()
{
#bla
}

idem.

C’était donc ça ! Le tropisme anti-briton de spip ressort donc même là où on l’attend le moins !

(^_^)

Mes 2 sous

et je rajoute un kopek :wink:

J’arrondis à 5 yuans

Sur ce, à bientôt.

Simon

11

Le 07/05/2010 17:41, Gilles VINCENT a écrit :

Et enfin l'indentention souvent c'est une tabulation de 4 espaces.
>

Perso je préfère la liberté offerte par la tabulation en début de ligne :
en effet mon IDE est réglé à 8caractères pour une tabulation, j'aime bien
prendre de l'espace:)

Plus prosaïquement, les tabulations sont déjà utilisées presque partout,
donc à mon avis c'est devenu une règle "d'usage"

et boum! ton fichier YAML est mort! cf YAML — Wikipédia

12

2010/5/10 cy_altern <cy_altern@yahoo.fr>

Le 07/05/2010 17:41, Gilles VINCENT a écrit :

Et enfin l’indentention souvent c’est une tabulation de 4 espaces.

Perso je préfère la liberté offerte par la tabulation en début de ligne :
en effet mon IDE est réglé à 8caractères pour une tabulation, j’aime bien
prendre de l’espace:)

Plus prosaïquement, les tabulations sont déjà utilisées presque partout,
donc à mon avis c’est devenu une règle « d’usage »

et boum! ton fichier YAML est mort! cf http://fr.wikipedia.org/wiki/Yaml#Caract.C3.A9ristiques

Je parle des codes PHP, pas des squelettes ou YAML