Discussion :

[Hinault Romaric]

Quelle est la règle de codage la plus étrange que vous avez été forcé de suivre ?
Faîtes-nous part de vos anecdotes

Dans toute équipe de développement, des règles et des standards de conception sont adoptés tout le long du cycle de développement du produit.

En dehors des bonnes pratiques et des patrons de conceptions ou tout autre standard permettant de coder proprement, certaines équipes disposent d’autres règles de codage qui doivent être obligatoirement appliquées par les développeurs.

Si l’on trouve certaines règles assez utiles pour avoir un produit de qualité, d’autres par contre sont étranges, drôles ou pire, n’ont pratiquement aucun sens.

Dans un post sur le sujet sur le forum US stackoverflow, voici quelques règles drôles qui y sont recensées : l'interdiction d’utiliser des retours multiples ; l’obligation de faire précéder les noms des tables de la base de données des caractères « tbl », l’imposition d’un nombre d’espaces pour l’indentation ou encore l’utilisation de l’inversion de l’indentation. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
     for(int i = 0; i < 10; i++)
        {
myFunc();
        }

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
  if(something)
          {
// do A
           }
    else
         {
// do B
         }

Et vous ?

Quelles règles de codage étranges avez-vous dû suivre ?

[Kaamo]

l’imposition d’un nombre d’espaces pour l’indentation

En quoi cette règle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve ça plutôt important de spécifier le nombre d'espaces pour l'indentation.
Surtout que selon le vécu du développeur, l'indentation diffère fortement (je pense au style GNU, différent de celui du C, ou Java etc).

[LooserBoy]

En quoi cette règle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve ça plutôt important de spécifier le nombre d'espaces pour l'indentation.
Surtout que selon le vécu du développeur, l'indentation diffère fortement (je pense au style GNU, différent de celui du C, ou Java etc).

Pourquoi ne pas utiliser la tabulation et choisir comment l'éditeur va la représenter à l'écran?
Ce ne serait pas mieux?

[Melem]

l'interdiction d’utiliser des retours multiples

En général, je suis plutôt pour cette interdiction. Notamment en langage C. Comapez les codes suivants :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int do_stuff(void) {
    int ret = 0;
    type1_t *p1 = type1_new();
 
    if (!p1) {
        ret = -1;
    } else {
        type2_t *p2 = type2_new();
 
        if (!p2) {
            ret = -2;
        } else {
            now_do_useful_stuff();
 
            type2_delete(&p2);
        }
 
        type1_delete(&p1);        
    }
 
    return ret;
}

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int do_stuff(void) {
    type1_t *p1 = type1_new();
 
    if (!p1) {
        return -1;
    }
 
    type2_t *p2 = type2_new();
 
    if (!p2) {
        type1_delete(&p1);
        return -2;
    }
 
    now_do_useful_stuff();
 
    type2_delete(&p2);
    type1_delete(&p1);        
}

Dans la deuxième version, avec retours multiples, type1_delete est appelée à deux endroits différents. Il y a donc une mauvaise factorisation du code. Et plus on a des allocations, plus les répétitions seront nombreuses. Et ce nombre augmente aussi avec le nombre de points de retour dans la fonction. Car il faut faire le nettoyage avant chaque return. En général. En clair, il vaut mieux bannir les retours multiples. L'exception est peut-être lorsqu'on implémente un algo déjà bien connu. Dans les autres cas, je recommande l'utilisation d'un seul retour.

l’imposition d’un nombre d’espaces pour l’indentation

Ici aussi je suis pour. Il faut soit imposer un nombre d'espaces, soit imposer l'utilisation de tabulation, mais il ne faut jamais mélanger les deux en tous cas. Pour avoir un max de compatibilité avec les divers éditeurs et afficheurs de texte, il vaut mieux préférer la première.

l’utilisation de l’inversion de l’indentation

Ca c'est fort ! Je n'en ai jamais entendu parlé et je ne saisis pas l'intérêt.

Sinon, pour les règles de codage bizarres que l'on a m'a déjà imposées, l'else if de la sorte :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if (condition1) {
    action1();
} else
if (condition2) {
    action2();
} else {
    action_par_defaut();
}

Tout le monde met else et if sur la même ligne quand même .

[air-dex]

En général, je suis plutôt pour cette interdiction. Notamment en langage C. Comapez les codes suivants :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int do_stuff(void) {
    int ret = 0;
    type1_t *p1 = type1_new();
 
    if (!p1) {
        ret = -1;
    } else {
        type2_t *p2 = type2_new();
 
        if (!p2) {
            ret = -2;
        } else {
            now_do_useful_stuff();
 
            type2_delete(&p2);
        }
 
        type1_delete(&p1);        
    }
 
    return ret;
}

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int do_stuff(void) {
    type1_t *p1 = type1_new();
 
    if (!p1) {
        return -1;
    }
 
    type2_t *p2 = type2_new();
 
    if (!p2) {
        type1_delete(&p1);
        return -2;
    }
 
    now_do_useful_stuff();
 
    type2_delete(&p2);
    type1_delete(&p1);        
}

Dans la deuxième version, avec retours multiples, type1_delete est appelée à deux endroits différents. Il y a donc une mauvaise factorisation du code. Et plus on a des allocations, plus les répétitions seront nombreuses. Et ce nombre augmente aussi avec le nombre de points de retour dans la fonction. Car il faut faire le nettoyage avant chaque return. En général. En clair, il vaut mieux bannir les retours multiples. L'exception est peut-être lorsqu'on implémente un algo déjà bien connu. Dans les autres cas, je recommande l'utilisation d'un seul retour.

Il y a aussi la lisibilité du code à prendre en compte. Et dans ce cas la deuxième version est bien plus indiquée. Et puis l'exemple ne prend pas en exemple les niveaux d'indentation de now_do_useful_stuff(); à prendre en compte. Si t'as envie de te retrouver avec du code de now_do_useful_stuff(); en quasi alignement à droite sur ton IDE, c'est ton problème . En attendant je préfère personnellement garder mon code lisible, à gauche dans l'IDE et lutter contre cette "programmation boomerang" * en ayant des retours multiples.

Sinon, pour les règles de codage bizarres que l'on a m'a déjà imposées, l'else if de la sorte :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if (condition1) {
    action1();
} else
if (condition2) {
    action2();
} else {
    action_par_defaut();
}

Tout le monde met else et if sur la même ligne quand même .

À la limite, dans du code pas nettoyé ou pas optimisé, ceci peut-être acceptable :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if (condition1) {
    action1();
} else {
    if (condition2) {
        action2();
    } else {
        action_par_defaut();
    }
}

Mais pas en dehors.


* : "programmation boomerang" est une référence au niveau d'indentation croissant puis décroissant du code dû aux boucles, formant ainsi une ligne (brisée) dont la forme évoque celle d'un boomerang. Le premier code de Melem permet de voir cela.

[abriotde]

À la limite, dans du code pas nettoyé ou pas optimisé, ceci peut-être acceptable :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if (condition1) {
    action1();
} else {
    if (condition2) {
        action2();
    } else {
        action_par_defaut();
    }
}

Mais pas en dehors.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int do_stuff(void) {
    int ret=0;
    type1_t *p1 = type1_new();
 
    if (!p1) {
        ret=-1;
    }
 
    type2_t *p2 = type2_new();
 
    if (!p2) {
        type1_delete(&p1);
        ret=-2;
    }
    if(ret=0){
      now_do_useful_stuff();
      type2_delete(&p2);
      type1_delete(&p1);        
    }
    return ret;
}

Avoir un seul return en fin clarifie parfois le code. Dans notre cas ou se sont juste de petits tests de conditions initial ce n'est pas justifier. Mais il faut éviter de multiplier ces return partout. Une solution : une variable que l'on ajoute comme ici. On évite le code boomerang.

[neopium]

Pourquoi ne pas utiliser la tabulation et choisir comment l'éditeur va la représenter à l'écran?
Ce ne serait pas mieux?

Parce que les tabulations ne sont pas encodées de la même manière d'une plate-forme à une autre et que si vous avez des développeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galère.

Idem pour le nombre d'espaces, si vous versionnez vos code sous SVN ou Git, c'est l'enfer si chacun utilise un nombre d'espaces différents

[Bluedeep]

Parce que les tabulations ne sont pas encodées de la même manière d'une plate-forme à une autre et que si vous avez des développeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galère.

La tabulation c'est le code 9 sous tous les systèmes utilisant de l'ASCII. Merci de ne pas raconter n'importe quoi. C'est la convention fin de ligne et retour début de ligne qui varie suivant les systèmes (LF ou CR+LF, le couple CR+LF étant la norme pour les imprimantes "lignes", certains systèmes l'utilisent aussi pour les écrans, d'autres considèrent que le saut de ligne doit obligatoirement s'accompagner du retour début de ligne).

[Barsy]

Pourquoi ne pas utiliser la tabulation et choisir comment l'éditeur va la représenter à l'écran?
Ce ne serait pas mieux?

Parce qu'il est certains cas où il faut que l'indentation se fasse au niveau d'un caractère de la ligne du dessus. Par exemple ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
                           NULL, NULL, JSPROP_ENUMERATE))

Ici la deuxième ligne doit être alignés sur la parenthèse ouvrante de la première ligne. C'est impossible à faire si on utilise des tabulations.

Beaucoup d'IDE remplacent par défaut les tabulations par des espaces.

Découper à outrance les classes dans de multiples dll (presque 1dll = 1 classe)

j'ai vu un projet un peu dans le même genre, mais au lieu d'y avoir une DLL par classe, les classes étaient découpées en 3 DLL : une DLL avec les attributs/accesseurs des classes, une avec les méthodes et la troisième avec les interfaces. Ça rend impossible l'utilisation de "private", tout doit être "public". Et à lire c'est bordélique, la classe AVoiture contient les attributs, la classe MVoiture les méthodes avec en attribut un élément de type AVoiture.

Bref, pourquoi faire simple quand on peut se casser le cul ?

[Joker-eph]

Parce qu'il est certains cas où il faut que l'indentation se fasse au niveau d'un caractère de la ligne du dessus. Par exemple ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
                           NULL, NULL, JSPROP_ENUMERATE))

Ici la deuxième ligne doit être alignés sur la parenthèse ouvrante de la première ligne. C'est impossible à faire si on utilise des tabulations.

Mouais... ici il suffit de mettre autant de tabulations que pour le "if" et de ne mettre des espaces que pour indenter relativement au if.

Beaucoup d'IDE remplacent par défaut les tabulations par des espaces.

Mauvais IDE, changer d'IDE

[Klaim]

Sacree thread. Ya des trucs qui m'ont bien fait rire (le coup du ; a la ligne 80 en particulier).

Concernant les retours multiples, voici ma philosophie concernant les breaks et continue, qui est liee (avec laquelle beaucoup de devs semblent etre d'accord: http://programmers.stackexchange.com...es/58253#58253)

When used at the start of a block, as first checks made, they act like preconditions, so it's good.

When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.

Pour moi c'est pareil pour les retours en milieu de fonction. En soit je trouve que c'est une tres mauvaise idee de les interdire parceque ca empeche tout ce qui est tests de preconditions.

Les fonctions, lorsquelles sont lues, le sont de haut en bas. Il est facile de reperer une return si il est proche du debut de la fonction et associe a un if et que le bloc du if est court.
C'est encore plus facile a lire si ca se repete parcequ'il y a plusieurs preconditions pour arriver au traitement final (je ne parle pas d'erreur ou d'assertions ici, c'est plus comme le pattern pipeline).

En revanche des que le return est planque au milieu d'un bout de code, ca peut etre tellement surprenant qu'en le survolant on ne le voit pas.

Donc en gros, c'est un peu se tirer une balle dans le pied (no pun intened) de s'interdire les retours multiples parceque ca encourage un style en arbre de condition qui est tres difficile a lire passe le 2nd niveau de profondeur. C'est un peu comme s'assurer qu'on ne pourra jamais avoir de code structure de maniere lisible.

Mettre les retours de maniere evidente, lisible et correcte est beacoup plus facile quand on a pas des barriere inutiles.

[Bluedeep]

Mauvais IDE, changer d'IDE

Le paramétrer correctement est une solution moins radicale et plus facile à maître en oeuvre.

[saccoche]

En quoi cette règle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve ça plutôt important de spécifier le nombre d'espaces pour l'indentation.
Surtout que selon le vécu du développeur, l'indentation diffère fortement (je pense au style GNU, différent de celui du C, ou Java etc).

Je confirme que les merges sont ingérables sans ce genre de cas.

[Freem]

D'un autre côté, les espaces... bon, si vraiment ça gêne un dev, il utilise un outil pour les mettre à sa sauce, puis un outil pour les mettre à la sauce de l'équipe, et basta...

(D'ailleurs, je me demande si cette procédure n'est pas automatisable avec git, faudra que je cherche, un jour)

Dans mon cas, je dirais, développer en français. Ce n'est pas bizarre en soit, mais je suis tellement rôdé à taper des noms anglais que je dois réfléchir 2 minutes avant de trouver un nom français assez court et représentatif. Pire que le scrabble...

Sinon, l'inversion de tab, c'est... moche

PS: pour ceux qui aiment python pour son indentation forcée: personnellement, c'est justement le genre de trucs que je n'apprécierais pas. Il arrive que mettre 2 instructions sur la même ligne soit pertinent au regard de la lisibilité et rende le tout plus simple à lire.
Bon, après, question de style, bien sûr, et puis, ça a l'avantage d'imposer aux débutants de bonnes habitudes.

[Kaamo]

Pourquoi ne pas utiliser la tabulation et choisir comment l'éditeur va la représenter à l'écran?
Ce ne serait pas mieux?

Le problème c'est que chaque environnement va interpréter le "caractère TAB" de différentes façons.

"TAB" est bien trop volatile et a évolué différemment selon l'histoire. Est-ce qu'un TAB c'est une colonne multiple de 8 ? (UNIX) Est-ce qu'un TAB c'est une colonne multiple de 4 ? (Win, Mac) Est-ce qu'un TAB c'est une colonne multiple de 2 ? (Ceux qui pensent que 4 créent trop d'espace vide ).

C'est pourquoi on a imposé une configuration de l'IDE pour chaque nouveau développeur qui rejoint notre projet :
- Expand Tabs to Spaces
- Number of Spaces by Indent : 2

Et comme l'a mentionné saccoche (edit : et les autres), c'est pour que les merges ne deviennent pas un truc ingérable et que le code soit interopérable qu'importe le système/IDE utilis

[Uther]

Heureusement que des langages comme python évite ce genre de dérive.

Pour tomber dans la dérive inverse

D'un autre côté, les espaces... bon, si vraiment ça gêne un dev, il utilise un outil pour les mettre à sa sauce, puis un outil pour les mettre à la sauce de l'équipe, et basta...

Certes mais le reformateur de code automatique, ça peux aussi faire des horreurs parfois.

Dans mon cas, je dirais, développer en français. Ce n'est pas bizarre en soit, mais je suis tellement rôdé à taper des noms anglais que je dois réfléchir 2 minutes avant de trouver un nom français assez court et représentatif. Pire que le scrabble...

Je dirais que le plus gros problème c'est que ça finis presque systématiquement par tourner au Franglais. Du coup on ne sait plus si on a un Bouton ou un Button, un statut ou un status, ...

Parce que les tabulations ne sont pas encodées de la même manière d'une plate-forme à une autre et que si vous avez des développeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galère.

Les tabulation sont heureusement encodée pareil, quelque soit l'OS.

Parce qu'il est certains cas où il faut que l'indentation se fasse au niveau d'un caractère de la ligne du dessus. Par exemple ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
                           NULL, NULL, JSPROP_ENUMERATE))

Ici la deuxième ligne doit être alignés sur la parenthèse ouvrante de la première ligne. C'est impossible à faire si on utilise des tabulations.

Dans ce cas là il faudrait idéalement utiliser, à la fois les tabulations et les espaces :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
--->if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
--->.......................NULL, NULL, JSPROP_ENUMERATE)) 
--->{
--->--->// Plein de code ....
--->}

Dans le meilleurs des mondes, les tabulations devraient marquer l'indentation, les espaces l'alignement. Ainsi tout le monde pourrait choisir la taille de ses tabulation, à sa guise.
Le problème c'est que comme chacun fait sa sauce, au final on fini par aller au plus simple, c'est espaces partout

[leminipouce]

Je confirme que les merges sont ingérables sans ce genre de cas.

Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les différences d'espaces dans les merges !

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

A titre de comparaison, avez-vous déjà vu un livre, ou la police serait différente d'une page à l'autre, ou la mise en page varierait d'un chapitre ou paragraphe au suivant. C'est fatiguant à lire. Pour moi, il en va de même pour le code : on doit pouvoir le lire comme si un seul développeur l'avait écrit.

[Bluedeep]

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.

[Barsy]

Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.

Quand il y en a un...

[andry.aime]

Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les différences d'espaces dans les merges !

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

Nous on travaille sur Eclipse et on crée un Template pour le Code Style que l'on partage à tous les développeurs pour éviter ce genre de problème. Un simple "Clean up" permet de formater tous le projet .