IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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
184 commentaires

48PARTAGES

5  6 
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 
1
2
3
4
5
     for(int i = 0; i < 10; i++)
        {
myFunc();
        }
et

Code : Sélectionner tout 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

184 commentaires
Commenter Signaler un problème
Kaamo
Avatar de Kaamo
Membre émérite https://www.developpez.com
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).
28  0 
pmithrandir
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 08/02/2013 à 13:48
Citation Envoyé par BenoitM Voir le message
Me semble qu'on m'a toujours dit le contraire.
Les Exceptions sont lourd à traité

puis bon quelle est la différence entre un return -1; et un throw new Exception? :p
Les exceptions ont plusieurs avantages :
- elles sont rapides, en particulier lorsque l'exception est rare. Si c'est un comportement courant, on doit utiliser un if.(bref, on utilise pas les exceptions pour remplacer le if).
- Elles ont un nom, un contenu, un détail... bref, elles sont bien plus parlante et détaillées qu'un "-1"
- Elles font partie des règles générales. On a créé les exceptions pour gérer les erreurs, utiliser un autre système va rendre la tache plus difficile pour les autres développeurs.
- elle peuvent passer très facilement d'un niveau à l'autre de programmation... elle ont cette capacité a traverser les couches bien pratique selon le besoin.
- elles permettent de concentrer le code sur le besoin fonctionnel d'un coté, et les erreurs de l'autre(on les voit facilement)

Pour toutes ces raisons, au moins, je pense qu'il est largement préférable de se servir des exceptions si on les as à notre disposition.
12  0 
pyros
Avatar de pyros
Membre expérimenté https://www.developpez.com
Le 11/12/2012 à 9:13
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 
1
2
3
4
5
6
7
8
9
if ( toto )
{
  [...]
}
else
{
  // NOTHING
}
9  0 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 11/12/2012 à 17:57
Citation Envoyé par Barsy Voir le message
Mais les codes que tu présentes ci-dessus, c'est dans le meilleur des mondes. Dans la réalité, il n'est pas rare de tomber sur des codes avec des méthodes bourrées de return et même au mileu des boucles.

C'est comme pour le code à base de goto ci-dessus. C'est facile tous les label sont à la fin de la méthode. C'est rarement le résultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...
Oh non tu te trompes, j'écris du code comme ça très souvent et je vis certainement dans un monde très exigent s'il en est. Et il y a pire que ça : j'accepte aussi de sortir d'une boucle par un return (le salaud ).

Après que se passe-t-il si jamais je commence à avoir besoin de return partout? Ben je refactore, genre je délègue les cas particuliers à de nouvelles méthodes. En fait il est rare que je dépasse le 2 niveaux d'indentation dans une méthode et si je dois scroller ou analyer les parenthèses pour comprendre le flux de mon traitement il y a une petite voix qui me dit "t'es peut être en train de faire de la merde", "ta méthode elle fait peut être trop de choses".

Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la réflexion, pré-condition non remplie? -> hop tu dégages d'ici. L'objet en cours est une pomme? -> hop délègue à la méthode des pommes. Si tu te mets bien dans la peau d'une personne qui lit ton code naturellement de haut en bas, t'arrives bien à représenter la logique de ton traitement en utilisant des return *par exemple* de sous-méthodes.
8  0 
Barsy
Avatar de Barsy
Expert confirmé https://www.developpez.com
Le 07/01/2013 à 14:49
Citation Envoyé par clampin Voir le message
Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxième mot, la première lettre du second mot en majuscule et le reste en minuscule....

par exemple une fonction qui ouvre un fichier...

Code : Sélectionner tout 
1
2
3
4
5
void ouvrirFichier()
{
 ....
}
Tout ce qu'il y a de plus normal quoi...
8  0 
raimbow
Avatar de raimbow
Nouveau membre du Club https://www.developpez.com
Le 10/01/2013 à 17:15
Si les procédures manger et faire la sieste sont utilisées plusieurs fois dans le logiciel, OK, ça vaut le coup de découper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher éventuellement dans quel fichier perdu est définie cette foutue fonction !
Le problème quand tu bosse sur des vrai programmes, c'est qu'ils sont amené à évolué d'une façon que tu ne peux pas prévoir (en fonction des besoins future du client) donc c'est impossible (la plupart de temps) de dire avec certitude si une fonction sera ou non utilisé plusieurs fois.

Et même pour la partie non-métier qui ne dépend pas de ton client, ton code évoluera si il est utilisé, donc y'a des chances qu'une fonction soit réutilisé à un autre endroit de ton code même si au départ ça ne devait pas être le cas.

Pour l'argument du "Si on découpe trop c'est chiant de retrouvé où sont les fonctions qui sont appelé" je te conseil d'utiliser un vrai IDE. Sous eclipse par exemple CTRL + clic sur une méthode m'ouvre le bon fichier à l'endroit où est définis la fonction.

Découper en fonction courte son programme permet également d'optimiser plus facilement son code en limitant les risques de tout casser. Par exemple sur une grande fonction, une variable qu'on utilise au début peut aussi être utilisé à un autre endroit, parfois un peu obscure (genre l'index d'un tableau), et il faut parcourir tout le code pour vérifier que ce n'est pas le cas. Sur une fonction de 5/10 lignes on le voit tout de suite.

C'est aussi plus facile à débugger souvent. Tu check les entrés sorties des fonctions et tu vois où ça merde. Une fois que t'as trouvé la fonction qui pose problème t'as au max 15 lignes à analyser. Si c'est sur une fonction de 250 Lignes, tu va encore passer un bon moment à trouver les lignes qui posent problèmes avant de te pencher réellement sur le problème en lui même.

Pareil pour les audits de performances, tu fais des bench sur chaque fonction et tu vois directement lesquelles ils faut optimiser, c'est bien plus simple !
8  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 10/12/2012 à 18:28
Citation Envoyé par fregolo52 Voir le message
Heureusement que des langages comme python évite ce genre de dérive.
Pour tomber dans la dérive inverse

Citation Envoyé par Freem Voir le message
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.

Citation Envoyé par Freem Voir le message
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, ...

Citation Envoyé par neopium Voir le message
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.

Citation Envoyé par Barsy Voir le message
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 
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 
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
9  2 
nickyla
Avatar de nickyla
Membre actif https://www.developpez.com
Le 11/12/2012 à 2:12
Citation Envoyé par NevilClavain Voir le message
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
7  0 
abriotde
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 11/12/2012 à 8:47
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.
7  0 
Bluedeep
Avatar de Bluedeep
Inactif https://www.developpez.com
Le 11/12/2012 à 9:39
Citation Envoyé par neopium Voir le message
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).
7  0 
Commenter Signaler un problème