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]

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

- Les préfixages tb pour les tables, ps(i/u/d/s) pour les procs, tr(i/u/d) pour les triggers,... le tout sur des bdds comme SqlServer ou Oracle...
- Indenter le code seulement avec des espaces, surtout pas de tabulations... Chacun indentant au niveau où ça lui plait (2/3/4 espaces selon les cas...)
- Convention de nommage donnant des nom de variables longs comme des jours sans internet avec rien à faire...
- Découper à outrance les classes dans de multiples dll (presque 1dll = 1 classe)

Heu... Je pense avoir fait le tour...

[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?

[CARNIBAL]

L'obligation de développer sans bug ... non je plaisante !

[fregolo52]

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

Je suis habitué au K&R et que je vois du Whitesmiths, j'ai un peu de mal.
Article wikipédia sur les indentations du code.

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

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

[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

[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 ?

[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

[Lynix]

Actuellement en fac d'info et ma prof de C interdit l'utilisation du else if car elle ne trouve pas ça clair...

[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

[loufab]

Composer des requêtes dans le code alors qu'elles n'ont rien de dynamiques.
Composer des requêtes dans le code alors qu'elles supportent aisément des fonctions natives.

Ceux qui pratique MS ACCESS comprendront...

[Darkzinus]

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

Tout à fait d'accord ! Une standardisation permet de lire bien plus aisément le code. En cobol typiquement, je pense même que c'est indispensable par exemple (généralement une indentation de 3).

[Bluedeep]

La régle la plus étrange ?

Pour ma part, et sans hésiter, il y a de cela sept ou huit ans, un projet chez un client où le DBA ne voulait pas de procédure stockées ....

[CinePhil]

l'interdiction d’utiliser des retours multiples ;

Euh... c'est quoi des "retours multiples" ?

l’obligation de faire précéder les noms des tables de la base de données des caractères « tbl »

Préfixer une table avec "tbl" n'apporte rien. Par contre, préfixer les tables comme le préconise SQLPro apporte une information (mon standard adapté de celui de SQLPro) :
- te_ pour les tables issues des entités types du MCD ;
- tj_ pour les tables de jointure, donc les tables issues des associations du MCD ;
- th_ pour les tables issues d'un héritage ;
- tr_ pour les tables de référence (pays, type, famille, civilité...).

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

Ça ce n'est pas idiot du tout mais il vaut mieux carrément utiliser la tabulation pour indenter, tant que le langage utilisé n'impose pas autre chose.
La variabilité de la taille des tabulations d'un système à l'autre est un faux problème.
Chez moi, la tabulation vaut 4 caractères. Dans les balises CODE sur DVP, elles valent 8 caractères. L'alignement est respecté dans les deux cas.
Ce qu'il faut à tout prix éviter, c'est des indentations de taille variable à l'aide d'espaces dans le même programme. On finit par ne plus savoir à quel bloc appartient telle ligne et c'est l'horreur à déboguer. Et je ne parle pas de ceux qui codent au kilomètre sans indentation du tout !

l’utilisation de l’inversion de l’indentation

Jamais vu ça ! Quel est le dictateur tordu qui impose cette connerie ?

Il paraît qu'il existe un standard de nommage dans les BDD de l'État (ou de mon ministère, je ne sais pas exactement) et je le trouve imbuvable, au vu d'une des BDD codées de la sorte dont j'ai à m'occuper de temps en temps !
Comme les BDD que je crée sont uniquement à usage interne et que je suis le seul DBA, j'applique mon standard.

[SylvainPV]

Les retours multiples, c'est comme son nom l'indique lorsqu'une fonction a plusieurs instructions return à l'intérieur de structures conditionnelles.

Sinon la règle de codage la plus étrange que j'ai eu fût de ne pas dépasser 80 caractères à chaque ligne (espaces d'indentation compris !). Parfois on été obligés de passer un argument de fonction par ligne, même s'il n'y en avait qu'un seul

[NevilClavain]

l’imposition d’un nombre d’espaces pour l’indentation c'est pas si débile que ça, parce que mettre un caractère TAB ça peut potentiellement foutre un bordel monstre quand on trimbale les sources d'un éditeur à l'autre (cas des applis multi-plateforme)