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

À l'époque du C++, nous n'étions pas autorisés à utiliser ==, >=, <=, &&, etc. Il existait des macros pour cela...

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

Il s'agissait manifestement de résoudre le problème de l'"ancienne affectation accidentelle dans une condition". également avait la règle "mettre les constantes avant les variables", donc

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

Je viens de me rappeler que la norme de codage la plus simple que j'ai jamais entendue était "Écrire du code comme si le prochain mainteneur était un psychopathe vicieux qui sait où vous vivez".

Answer 2

La notation hongroise en général.

Answer 3

J'ai eu beaucoup de stupide des règles, mais pas beaucoup de choses que j'ai considérées comme carrément étranges.

Le plus idiot était sur un travail de la NASA que j'ai effectué au début des années 90. C'était un travail énorme, avec bien plus de 100 développeurs. Les développeurs expérimentés qui ont rédigé les normes de codage ont décidé que chaque fichier source devait commencer par un acronyme de quatre lettres, la première lettre devant représenter le groupe responsable du fichier. C'était probablement une excellente idée pour les vieux projets FORTRAN 77 auxquels ils étaient habitués.

Cependant, il s'agissait d'un Ada avec une belle structure de bibliothèque hiérarchique, ce qui n'avait aucun sens. Chaque répertoire était rempli de fichiers commençant par la même lettre, suivie de trois autres lettres absurdes, d'un trait de soulignement, puis de la partie du nom de fichier qui importait. Tous les paquets Ada devaient commencer par cette même verrue de cinq caractères. Les clauses Ada "use" n'étaient pas autorisées non plus (ce qui peut être une bonne chose dans des circonstances normales), ce qui signifiait que toute référence à un identifiant qui n'était pas local à ce fichier source devait être interdite. également a dû inclure cette verrue inutile. Il y aurait probablement dû y avoir une insurrection à ce sujet, mais l'ensemble du projet était composé de programmeurs juniors et de nouvelles recrues fraîchement sorties de l'université (moi-même étant ce dernier cas).

Une instruction d'affectation typique (déjà verbeuse en Ada) ressemblerait à quelque chose comme ceci :

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

Heureusement, ils ont au moins été assez éclairés pour nous permettre d'utiliser plus de 80 colonnes ! Pourtant, la verrue de l'installation était suffisamment détestée pour qu'elle devienne un code passe-partout en haut des fichiers sources de tout le monde pour utiliser les "renommages" Ada afin de se débarrasser de la verrue. Il y avait un renommage pour chaque paquet importé ("withed"). Comme ceci :

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

Les plus créatifs d'entre nous ont essayé de faire en sorte que utiliser la verrue pour faire un nom de paquet réellement sensé (ou stupide). (Je sais ce que vous pensez, mais les explosifs n'étaient pas autorisés et vous devriez avoir honte ! C'est dégoûtant). Par exemple, j'étais dans le C et j'avais besoin de créer un paquet pour faire l'interface avec le groupe de code W groupe de postes de travail. Après une séance de brainstorming avec le gars de Workstation, nous avons décidé de nommer nos paquets de manière à ce que quelqu'un qui a besoin des deux ait à écrire :

with CANT_Interface_Package;
with WONT_Interface_Package;

Answer 4

Effectuer toutes les requêtes de base de données via des procédures stockées dans Sql Server 2000. Des requêtes complexes multi-tables aux requêtes simples comme :

select id, name from people

Les arguments en faveur des procédures étaient les suivants :

• Performance
• Sécurité
• Maintenabilité

Je sais que le sujet de la procédure est assez controversé, alors n'hésitez pas à noter ma réponse négativement ;)

Answer 5

Il doit y avoir 165 tests unitaires (pas nécessairement automatisés) pour 1000 lignes de code. Cela correspond à un test toutes les 8 lignes environ.

Inutile de dire que certaines lignes de code sont assez longues, et que les fonctions retournent ce pour permettre le chaînage.