Discussion :

[NevilClavain]

ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.

[Lynix]

J'ai également oublié l'interdiction du mot-clé "break" car "ce n'est pas une façon propre de sortir de la boucle"

[Barsy]

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

Je ne trouve pas ça stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une méthode qui retourne une valeur, par exemple un int, je commence ma méthode par "int result" et je la termine par "return result". Et je ne mets pas d'autres "return" au milieu.

Ça permet d'éviter d'avoir des fonctions avec des "return" planqués, des fonctions avec du code mort situé après un "return". Personnellement, c'est le genre de règle que j'applique constamment.

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

Ça non plus ce n'est pas forcément idiot. Combien de fois on voit du code avec des lignes de 500 caractères qui imposent un scroll horizontal. Après, il faut adapter la taille des lignes en fonction des écrans des développeurs. 80 caractères c'est court, sur mon dernier projet on avait imposer 200 caractères maximum.

C'est ainsi qu'on se rend compte que des règles qui semblent étranges à certains peuvent aller de soit pour d'autres. Par exemple le préfixage des variables, je ne l'ai jamais fait, mais je peux comprendre la raison qui poussent certains à l'appliquer.
De même, dans un autre topic (il y a fort longtemps), quelqu'un se plaignait qu'on lui impose d'écrire "if (monBooléen == true)" au lieu de juste "if (monBooléen)" (et normalement il faut écrire "if (true == monBooléen)"). Pour ça aussi je peux comprendre qu'il y en ait qui l'impose.

Bref, les règles de codage, je pense que peut importe qu'elles semblent stupide ou non, le principal c'est que tout le monde utilise les mêmes.

[Bluedeep]

ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.

Notation hongroise dans sa variante "System"; on a déjà débattu de cela; ça n'a en effet aucun sens avec les langages OO. La notation hongroise en variante "Apps" peut néanmoins se justifier dans certains cas.

[Bluedeep]

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)

A priori tous les IDE permettent le paramétrage du nombre d'espace "écran" associés à un caractère "tab", non ?

[Gugelhupf]

Deuxième page et aucune référence à Jenkins pour l'intégration continue et les conventions d'écriture

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

[nickyla]

ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.

Oui d'accord de manière générale,sauf si t'as la malheureuse expérience de développer avec un langage non typé style PHP orienté objet (par exemple), il y a des cas, si tu n'explicite le type dans le nom de la variable, si tu relis ton code quelques semaines plus tard, tu peux perdre pas mal de temps avant d'être à l'aise avec ton module ou même une simple classe

[andry.aime]

En java, l'utilisation de retour multiple est déconseillée par le "Code Convention". D'ailleurs, ça me rappelle un bug, au lieu d'utiliser un "break" pour quitter une boucle, le développeur à utiliser un return qui lui a éjecté de la fonction qui retourne un void .

Pour le Code Style, on a l'habitude de créer un Template dans eclipse et on le partage pour tous les développeurs.

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

On ne nous a pas laissé un tag auto-fermante pour déclarer des beans ou des propriétés des beans dans un fichier de configuration de spring.
Utiliser

Code xml :

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

1
2
3
4
5
<bean id="id1" class="com.package.class1">
</bean>
<bean id="id2" class="com.package.class2">
	<property name="id1" ref="id1"></property>
</bean>

à la place de

Code xml :

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

1
2
3
4
<bean id="id1" class="com.package.class1" />
<bean id="id2" class="com.package.class2">
	<property name="id1" ref="id1" />
</bean>

[BenoitM]

Perso je trouve plus lisible des return au début et au milieu que de s'amuser a vérifier si ma fonction fait encore quelque chose.

[abriotde]

Pour l'indentation, il y a bien plus inteligent et souple : la tabulation. Ainsi en changeant le nombre d'espace d'une tabulation, chacun adapte le formatage. Deplus, à taper c'est plus rapide (ne serais-ce que pour éffacer 3*3=9 espaces= 3 tabulation ).
Dans les codes indenté par des espaces vous remarquerez qu'ils sont toujours mal indenté car à un moment on à rajouté des espaces au pif. Je travaille beaucoup en directement en prod sous VIM qui ne rajoute pas automatiquement les espaces mais qui permet d'indenter rapidement le code en tabulation.

[grunk]

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

C'est un héritage historique des cartes perforées d'IBM qui avaient 80 colonnes.

Ensuite y se trouve que les vrais barbus sont bien connus pour encore coder sous vi sur un écran de 14 pouces , du coup les 80 caractères on encore du sens.

Plus qu'un nombre de caractères je pense qu'il faut absolument éviter le scroll horizontal et si possible éviter de devoir déplacer son regard de gauche à droite sans cesse pour lire un code.

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

[_skip]

Je ne trouve pas ça stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une méthode qui retourne une valeur, par exemple un int, je commence ma méthode par "int result" et je la termine par "return result". Et je ne mets pas d'autres "return" au milieu.

Ça permet d'éviter d'avoir des fonctions avec des "return" planqués, des fonctions avec du code mort situé après un "return". Personnellement, c'est le genre de règle que j'applique constamment.

Comme quoi les points de vue peuvent changer d'une personne à l'autre.

Perso je déclare les variables au moment où cela devient nécessaire en règle général. Par conséquent, en aucun cas je ne déclare une return value en début de la fonction en comptant sur le code qui suit pour la "garnir" convenablement. Sauf si la construction l'impose.

Pour ce qui est des retours multiples, je trouve ceci tout à fait acceptable :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public Service findService( String serviceName )
{
   
    if(  isKnown( serviceName ) )
          return cache.lookup( serviceName);
    
   //create and register
   //(..) 

   return newService;
}

ou ceci :

Code :

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

1
2
3
4
5
6
7
8
public void log( String message )
{
     if(  message== null || message.length < 1) )
          return ;
 
     //(...)   
}

Pourquoi?
Parce que cela décrit suffisamment bien le comportement de la fonction. Je ne parle pas de planter 36 return au milieu d'une ribambelle de if( else if() ).
L'important c'est que le travail de la méthode soit le plus lisible possible à la relecture, et pour ça il est parfois plus simple de l'imaginer comme une autoroute sur laquelle tu prends la première sortie si tu vois le bon panneau (où si tu réalises que t'es pas sur le bon chemin)..

[pyros]

Fraichement embauché sur un produit codé par des générations de stagiaires, j'ai voulu mettre en place des conventions de codage et un semblant d'architecture pour harmoniser tout ça. Le chef de projet m'a répondu que la seul règle à suivre était de ne pas utiliser de convention de codage car "ça frustre le développeur et lui fait perdre son temps. Tu débute et moi j'ai 20 ans d'expérience alors crois moi quand je te dis que ça sert à rien !".
Résultat, un code illisible mélangeant a peu près tout ce qu'on peu trouver...

Je suis partir au bout de 3 mois et la boite à coulé 6 mois après...

Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:

Code :

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

1
2
3
4
5
6
7
8
9
if ( toto )
{
  [...]
}
else
{
  // NOTHING
}

[NevilClavain]

A priori tous les IDE permettent le paramétrage du nombre d'espace "écran" associés à un caractère "tab", non ?

Moui, encore faut il avoir le réflexe de le faire AU DEBUT du projet, pas quand on en est à 100000 lignes/150 fichiers sources

[NevilClavain]

Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:

Code :

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

1
2
3
4
5
6
7
8
9
if ( toto )
{
  [...]
}
else
{
  // NOTHING
}

L'idée derrière cette règle c'est de mettre au moins une trace dans le else (ne serait-ce qu'un std::cout) pour voir quand tu tombes dans ce cas précis, ça peut te faire gagner un temps précieux de recherche. Juste mettre un commentaire NOTHING effectivement c'est lourdingue et surtout ça sert à rien...

[el_slapper]

une règle parmi les plus étranges que j'ai eu est la suivante : en cobol, pas de GO TO, sauf GO TO FIN-DE-PARAGRAPHE en cas d'erreur. Une espèce de break, quoi.

L'idée sous-jacente est de retirer un niveau d'indentation :

Code :

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

1
2
3
4
5
6
7
PARAGRAPHE.
    IF MONTANT NOT NUMERIC
       GO TO FIN-DE-PARAGRAPHE
    END IF
    blablabla...
    .
FIN-DE-PARAGRAPHE.

au lieu de

Code :

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

1
2
3
4
5
6
7
8
PARAGRAPHE.
    IF MONTANT NOT NUMERIC
       CONTINUE
    ELSE
       blablabla...
    END IF
.
FIN-DE-PARAGRAPHE.

ça a son utilité, surtout si blablabla... est fort verbeuse. Mais on peut toujours faire autrement, par exemple en gérant un sous-paragraphe qui ne fait que blablabla. A l'époque, j'avais appréçié, mais j'en suis revenu. Même si je le tolère désormais chez les autres.


Dans les langages modernes, le return multiple peut avoir son utilité, mais quand il passe entre de mauvaises mains, provoque assez vite des horreurs. Mon expérience, c'est qu'un code de production pérènne finit toujours par passer entre de mauvaises mains.

Enfin, je dirais que mieux vaut un mauvais standard appliqué par tous, qu'un mélange de bons standards incompatibles entre eux.

[Uther]

Moui, encore faut il avoir le réflexe de le faire AU DEBUT du projet, pas quand on en est à 100000 lignes/150 fichiers sources

Au contraire, tout l’intérêt d'indenter proprement avec des tabulation, c'est qu'on peut changer ça à n'importe quel moment sans que ça ait le moindre impact.
Tout le monde peut régler la taille des tabulation à la valeur qu'il souhaite personnellement sans impacter les autres.

[Katyucha]

L'obligation de commencer mes requêtes SQL... Même pour 2 lignes, je crois que ce fut un moment de solitude...