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.
L'exemple le plus étrange que j'ai vu était la dénomination des tables de la base de données où les tables étaient précédées d'un TLA pour le domaine fonctionnel, par exemple ACC de comptabilité, puis d'un numéro à 3 chiffres pour (remplacer le tri par défaut) et enfin le nom de la table.
De plus, cela a été étendu aux noms des colonnes.
ACC100_Code de compte
c'était un cauchemar de lire une requête, elles étaient si illisibles.
L'application de s_ aux variables et méthodes jugées "critiques pour la sécurité" pour un logiciel faisant partie d'un système de contrôle. Si l'on ajoute à cela l'autre règle consistant à mettre m_ devant les variables membres, on obtient quelque chose de ridicule comme "s_m_blah()", qui est très ennuyeux à écrire et pas très lisible à mon avis. En fin de compte, un "expert en sécurité" était censé avoir un aperçu du code et en tirer quelque chose en utilisant ces "s_" - dans la pratique, ils ne connaissaient pas trop bien le c++ et ne pouvaient donc pas faire grand chose d'autre que des rapports sur le nombre d'identifiants que nous avions marqués comme "critiques pour la sécurité". C'est complètement absurde...
C'était une norme de codage que je ne suivais pas moi-même (j'ai eu des problèmes pour d'autres choses, mais jamais pour ça). Nous avions trois moniteurs de 19 pouces, ce qui nous permettait d'avoir deux éditeurs ouverts en plein écran tout en ayant accès au bureau. Tous les autres n'utilisaient pas de commentaires, mais des noms significatifs. Des noms significatifs extrêmement longs. Le plus long dont je me souvienne était de l'ordre de 80 caractères. La moyenne était d'environ 40~50.
Devinez quoi, ils n'ont pas décrit avec précision l'ensemble de la chose.
Si je me souviens bien, l'IDE Delphi avait une indentation par défaut de deux espaces. La plupart du code hérité de l'entreprise comportait trois espaces et était écrit par le vice-président informatique et le PDG. Un jour, tous les programmeurs discutaient de ce que nous devrions faire pour nous faciliter la vie et un entrepreneur qui connaissait assez bien Delphi a dit : "Hé, l'IDE utilise par défaut deux espaces, est-ce que quelqu'un a un problème pour que nous fassions de même à l'avenir pour le nouveau code ?". Nous nous sommes tous regardés, avons pensé que c'était une évidence et avons dit que nous étions d'accord.
Deux jours plus tard, le vice-président et le directeur général ont appris que nous allions procéder à un changement aussi dangereux qui pourrait "causer des problèmes" et nous ont demandé d'utiliser trois retraits pour tout jusqu'à ce qu'ils puissent tous deux évaluer avec précision l'impact d'un tel changement. Je suis tout à fait favorable au respect des normes, mais ce sont les mêmes personnes qui pensaient que la programmation Oo consistait à créer un objet avec une seule fonction qui avait tous de la logique nécessaire pour effectuer une action, et que le contrôle de la source déplaçait les fichiers de code dans un autre répertoire.
Celui qui m'a interpellé était similaire au préfixe "tbl" de l'autre afficheur pour les noms de tables SQL.
Dans ce cas, le préfixe de toutes les procédures stockées devait être "sp_", bien que "sp_" soit un préfixe utilisé par Microsoft pour les procédures stockées au niveau du système dans SQL Server. En fait, ils avaient leurs normes à partir d'une ancienne base de données non-MS et n'étaient pas prêts à changer juste parce que leur norme pouvait faire entrer en collision une procédure stockée avec une procédure stockée système et produire des résultats imprévisibles. Non, ce ne serait pas correct.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
