Quelle est la règle de codage standard la plus étrange que vous ayez été obligé de suivre ?

Question

Quand j'ai demandé cette question J'ai presque toujours obtenu un oui définitif : vous devriez avoir des normes de codage.

Quelle est la règle de codage standard la plus étrange que vous ayez été obligé de suivre ?

Et par "le plus étrange", je veux dire le plus drôle, le pire, ou tout simplement le plus bizarre.

Dans chaque réponse, veuillez mentionner la langue, la taille de votre équipe et les effets négatifs que cela a eu sur vous et votre équipe.

Answer 1

On m'a dit que l'ancien code devait être commenté plutôt que supprimé, au cas où nous aurions besoin de faire référence à l'ancien code (oui, le code était dans le contrôle de la source...). Cela ne semble pas si grave, jusqu'à ce que des changements majeurs soient effectués. Alors cela devient un cauchemar, avec des sections entières supprimées partout dans le code.

Answer 2

J'ai travaillé dans un endroit où la norme de codage était un WTF géant : notation hongroise étrange, préfixation des globaux avec 'g' et des membres avec 'm' (il y avait donc des joyaux comme gsSomeVariable), ajout de 'ref string sError' à chaque fonction, au lieu de lancer des exceptions (ce qui était un GROS nono !).

Le problème, cependant, était de préfixer les paramètres de la fonction avec I_ pour les paramètres d'entrée et O_ pour les paramètres de sortie.

Je travaille maintenant dans un bien meilleur endroit :)

Answer 3

Pas de noms de variables à un seul caractère - même pour un simple itérateur comme i. Il fallait utiliser ii ou autre. Je pensais que c'était stupide.

Une autre - peut-être la plus folle de toutes, mais peut-être pas une norme de codage...

Aucun STL n'était autorisé. Et c'était en 2007/2008. J'ai quitté l'entreprise peu après avoir découvert cette absurdité. Apparemment, certains idiots pensaient qu'il n'y avait pas de "norme" (comme il y a 15 ans...) Je suppose qu'ils ont manqué le mémo sur le fait que stl était dans la norme C++...

Utilisation des stupides HRESULTs de COM comme types de retour pour pratiquement TOUTES les méthodes - même si elles ne sont pas COM. C'était grotesque. Ainsi, au lieu de renvoyer un type énuméré ou une valeur utile indiquant un résultat, etc., nous devions chercher ce que S_OK ou E_FAIL ou autre signifiait dans le contexte de chacune des méthodes. Encore une fois, je suis parti peu de temps après.

Answer 4

Sur Delphi nous avons dû passer de

if something then
begin
  ...
end
else
begin
 ...
end;

à

if something then begin
  ...
end else begin
 ...
end;

dans un projet comportant 1,5 million de lignes de code. Imaginez combien cela a été facile pour le contrôle de la source, le diff et le merge ! Cela a également conduit à oublier de commencer et de ne pas le remarquer tout de suite lorsque le compilateur a annoncé une fin superflue.

Answer 5

Nous devons mettre un commentaire au-dessus de chaque déclaration sql. Ainsi, vous pouvez avoir une instruction sql comme suit

Sélectionnez USER_ID FROM USERS OÙ NAME = :NAME ;

Et tu dois toujours avoir un commentaire au-dessus qui dirait :

Sélectionnez USER_ID dans la table USERS, où le nom est égal au nom saisi.

Maintenant, quand le commentaire est plus long que le code, et que le code est assez simple pour être lu par un élève de CE1, je ne vois vraiment pas l'intérêt de commenter... Mais, hélas, j'ai dû revenir en arrière et ajouter des commentaires à des déclarations comme celle-ci.

Cela s'est fait sur un ordinateur central, en codant en cobol. La taille de l'équipe est généralement de 4 ou 5 personnes, mais cette règle a frappé tout le monde ici de temps en temps.