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

Le , par Hinault Romaric, Responsable Actualités
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 :
1
2
3
4
5
 
     for(int i = 0; i < 10; i++) 
        { 
myFunc(); 
        }
et

Code :
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Kaamo Kaamo
http://www.developpez.com
Expert Confirmé
le 10/12/2012 16:17
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).
Avatar de LooserBoy LooserBoy
http://www.developpez.com
Membre Expert
le 10/12/2012 16:30
Citation Envoyé par Hinault Romaric  Voir le message
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...
Avatar de LooserBoy LooserBoy
http://www.developpez.com
Membre Expert
le 10/12/2012 16:31
Citation Envoyé par Kaamo  Voir le message
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?
Avatar de CARNIBAL CARNIBAL
http://www.developpez.com
Membre régulier
le 10/12/2012 16:40
L'obligation de développer sans bug ... non je plaisante !
Avatar de fregolo52 fregolo52
http://www.developpez.com
Expert Confirmé Sénior
le 10/12/2012 16:48
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.
Avatar de saccoche saccoche
http://www.developpez.com
Nouveau Membre du Club
le 10/12/2012 17:06
Citation Envoyé par Kaamo  Voir le message
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.
Avatar de Freem Freem
http://www.developpez.com
Expert Confirmé
le 10/12/2012 17:16
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.
Avatar de Melem Melem
http://www.developpez.com
Rédacteur/Modérateur
le 10/12/2012 17:30
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 :
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 :
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 :
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 .
Avatar de neopium neopium
http://www.developpez.com
Invité de passage
le 10/12/2012 17:34
Citation Envoyé par LooserBoy  Voir le message
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
Avatar de Barsy Barsy
http://www.developpez.com
Expert Confirmé
le 10/12/2012 17:38
Citation Envoyé par LooserBoy  Voir le message
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 :
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.

Citation Envoyé par LooserBoy
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 ?
Offres d'emploi IT
Sr dev ops engineer / ingénieur(e) systèmes h/f
CDI
Talend - Ile de France - Suresnes (92150)
Parue le 16/09/2014
Chef de projet technique java/j2ee
CDI
Opensourcing - Ile de France - Paris (75000)
Parue le 22/09/2014
développeur php5 zend h/f
CDI
JG CONSEIL RH SASU - Rhône Alpes - Lyon (69000)
Parue le 21/09/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula