La pire norme de codage que vous ayez eu à suivre? [fermé]

Avez-vous déjà eu à travailler selon des normes de codage qui:

• A considérablement diminué votre productivité?
• Ont-ils été inclus à l'origine pour de bonnes raisons, mais ont-ils été conservés longtemps après que la préoccupation initiale soit devenue sans objet?
• Étaient dans une liste si longue qu'il était impossible de se souvenir de tous?
• Vous avez pensé que l'auteur essayait juste de laisser sa marque plutôt que d'encourager de bonnes pratiques de codage?
• Vous ne saviez pas pourquoi ils étaient inclus?

Si oui, quelle est votre règle la moins préférée et pourquoi?

Quelques exemples ici

Cela peut ébouriffer quelques plumes, mais les normes qui imposent des commentaires de bloc basés sur un modèle en haut de chaque méthode me dérangent toujours.

1) Ils sont toujours obsolètes, car ils sont trop éloignés du code qui fait le travail pour que vous remarquiez lorsque vous mettez à jour des choses. Les mauvais commentaires sont pires que pas de commentaires.

2) Ils ne font souvent que répéter des informations déjà contenues dans l’outil de contrôle de source, mais moins précises. Par exemple: Dernière modification par, liste des date / raisons de modification.

Si un professeur avait déjà demandé, nous avions au moins un commentaire pour chaque ligne de code.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

C'était assez ridicule.

Notre norme de codage d'entreprise (C #) préconisait une utilisation intensive de #REGIONs (pour ceux qui l'ignorent, elle marque des blocs de code source qui seront réduits à une seule ligne dans Visual Studio). En conséquence, vous avez toujours ouvert ce qui semblait être une classe bien structurée, uniquement pour trouver des piles et des piles d'ordures balayées sous des tapis profondément imbriqués de constructions #REGION. Vous auriez même des régions autour de lignes simples, par exemple devoir plier une région LOG pour trouver une seule déclaration de l'enregistreur. Bien sûr, de nombreuses méthodes ajoutées après la création d’une région ont également été placées dans la "mauvaise" portée. L'horreur. L'horreur.

Les régions constituent l'une des pires fonctionnalités jamais ajoutées à Visual Studio. il encourage la structuration de la surface plutôt que la structure réelle de OO.

De nos jours, je tue des #REGIONs à vue.

Dans un travail, nous avons été forcés d'utiliser une forme étrange de notation hongroise dans la base de données.

Je ne me souviens pas des détails, mais de mémoire, chaque nom de champ devait contenir:

• Pas de voyelles
• Toutes les lettres majuscules
• Une référence à la table
• Un indicateur de type de données
• Une longueur de données
• Un indicateur nullable

Par exemple, la colonne contenant le prénom d'une personne peut s'appeler: PRSNFRSTNMVC30X(Table de personnes, colonne Prénom, Varchar 30 caractères, Non Null)

Insister pour que tous les accolades soient suivis d'un commentaire indiquant le but de l'accolade:

par exemple:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'Nuff a dit.

• Les noms de variables locales sont tous en minuscule sans soulignement

Des exemples concrets: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

Le New York Times pèse :

«Les espaces de mots ne doivent pas être pris pour acquis. Le grec ancien, le premier alphabet à comporter des voyelles, peut être déchiffré sans espaces de mots si vous le prononcez et vous le faites sans. […] Le latin a également cessé de séparer les mots dès le deuxième siècle. La perte est déconcertante, car l’œil doit travailler beaucoup plus fort pour lire un texte non séparé. Mais comme l'a expliqué le paléographe Paul Saenger, le monde antique ne souhaitait pas "rendre la lecture plus facile et plus rapide".

On m'a demandé par le leader mondial des logiciels d'une entreprise à faire « simple, re n du code redondantes ». Par exemple, il était interdit d'ajouter un nouveau paramètre à une fonction existante. Au lieu de cela, vous avez dû dupliquer la fonction, en laissant l'original intact afin d'éviter les régressions. Pas de test formel bien sûr (perte de temps).

Il nous était également interdit d'utiliser un logiciel de fusion; chaque fichier ne peut être modifié que par un programmeur à la fois. Le logiciel de contrôle de révision était de la science-fiction, bien sûr.

Le jour le plus heureux de ma vie a été celui où il a été licencié (considérez qu'il est très, très difficile de licencier quelqu'un en Italie).

Toutes les interactions avec la base de données doivent être effectuées via des procédures stockées . Cela pourrait avoir un sens si nous vivons en 1997 et non en 2010.

Je viens de me rendre compte que cela couvre en fait tous les critères de la question initiale:

• A considérablement diminué votre productivité? VÉRIFIER. S'il vous plaît - utilisez simplement un ORM .
• Ont-ils été inclus à l'origine pour de bonnes raisons, mais ont-ils été conservés longtemps après que la préoccupation initiale soit devenue sans objet? VÉRIFIER. Le responsable était développeur pour un serveur de base de données il y a 1000 ans et a mis cette norme de codage en oeuvre.
• Étaient dans une liste si longue qu'il était impossible de se souvenir de tous? VÉRIFIER. Cela incluait «autant de logique que possible devrait être stockée dans la base de données».
• Vous avez pensé que l'auteur essayait juste de laisser sa marque plutôt que d'encourager de bonnes pratiques de codage? VÉRIFIER. Continue à revenir au gestionnaire en tant que développeur de serveur de base de données.
• Vous ne saviez pas pourquoi ils étaient inclus? VÉRIFIER.

Ne pas être autorisé à utiliser la STL ou d'autres bibliothèques C ++ standard, car le CTO pensait que nous pouvions le faire mieux et plus rapidement. Même les constructions de base comme les listes et la classe string.

Notation hongroise

Échantillon extrait de " l'explication de Charles Simonyi de la convention de dénomination de l'identificateur de notation en hongrois " sur MSDN.

1 #include “sy.h”
2 extern int * rgwDic;
3 externe int bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 caractères * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 non signé wHash = 0;
13 pch = sz;
14 tant que (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 pour (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 tant que (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 retour (psy);
27}
28}
29 cwSz = 0;
30 si (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 zéro ((int *) psy, cwSY);
34 milliards de octets (sz, psy-> sz, cch + 1);
35 retour (psy);
36}

J'ai déjà travaillé sur un projet dans lequel le responsable du projet avait demandé que chaque variable - CHAQUE variable - soit précédée de "v". Donc, vCount, vFirstName, vIsWarranty, etc.

Pourquoi? "Parce que nous travaillons sous VBScript et que de toute façon, tout est une variante".

WTF.

Presque oublié celui-ci:

Citation d'un manager:

Ne corrigez pas et ne documentez pas les bugs des problèmes que vous trouvez dans votre propre code. Le client nous paiera pour les identifier et les réparer au cours des prochaines années.

Ce n'était pas pour les logiciels grand public, mais personnalisé pour une seule grande entreprise. Inutile de dire que le client a payé pour des années après. Cela peut sembler trivial, mais il est plus difficile d’ignorer les bogues que de les trouver.

Commentaires XML appliqués sur toutes les méthodes, constantes, enums et propriétés non privées.

Cela a conduit à un code assez encombré, en particulier parce que le résultat final était que les gens tapaient /// simplement pour créer un talon de commentaire vide ou installaient GhostDoc et le faisaient ajouter des commentaires générés automatiquement:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[Modifier] La raison pour laquelle je mentionne cela comme une norme ridicule n'est pas parce que je pense que les commentaires de méthode sont stupides mais parce que la qualité de ces commentaires n'était en aucun cas appliquée et avait pour conséquence de simplement créer beaucoup de fouillis dans les fichiers de code. . Il existe de meilleurs moyens de créer des documents de code significatifs que aveugle "doit avoir un commentaire", condition de génération requise.

Pas vraiment une norme de codage, mais nous avions un fichier dans le contrôle de source appelé 'changelog.txt'

Chaque fois que vous avez effectué un enregistrement, vous deviez ajouter manuellement une entrée dans ce fichier. Cette entrée était le numéro de révision de subversion et votre commentaire d’arrivée.

Lorsque le nouveau CTO a commencé et que quelqu'un lui a dit cela, il a rapidement pris une décision de l'exécutif et a déclaré: "Nous n'allons plus le faire" et a supprimé le fichier. Cela durait depuis des années.

Certains des endroits avec lesquels j'ai travaillé ont insisté pour commenter le code inutilisé ou obsolète au lieu de le supprimer. Au lieu de faire confiance au VCS pour l'historique, etc., il a été péniblement maintenu dans les fichiers par le biais d'un code commenté.

Le gros problème que j'ai trouvé avec ceci est que souvent vous ne saviez pas pourquoi le code était commenté. Est-ce parce que certains développeurs étaient en train de faire des changements et qu'ils voulaient le garder comme référence ou était-ce devenu inutile?

La pire norme de codage à laquelle j'ai jamais participé est celle des bases de code, qui n'en avaient aucune. Je préfère suivre une norme de codage avec laquelle je suis complètement en désaccord que de travailler dans des bases de codes où il n’en existe aucune. Cela rend d'autant plus difficile l'apprentissage de nouvelles parties de la base de code.

Forcer des commentaires en ligne pour le contrôle de version était à peu près la norme de codage la plus inutile que j'ignorais.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

Le DBA Oracle qui insistait sur l'utilisation correcte des espaces tout en "conservant" une base de données avec une table hautement contestée comportant plus de 200 champs et 40 déclencheurs se rapproche.

J'ai effectué des revues de code sur un projet dirigé par un premier temporisateur C ++ qui a décidé que toutes les fonctions de membre de classe devraient être précédées du nom et de la visibilité de la classe:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Être obligé d'indenter tout le code de quatre espaces;)

J'avais un travail il y a des années où tout notre code devait être aligné à gauche - pas d'indentation. Le gars qui a proposé cette politique n'aimait pas avoir à faire défiler les lignes de code horizontalement, ce qui équivaut à jouer au ping-pong avec ses yeux.

Ceci est un exemple de non-respect des normes de codage.

Un entrepreneur travaillant dans une grande banque a insisté sur le fait que le respect des normes était le meilleur de tous les temps. L'application était écrite en dBase / Clipper dont il était l'unique développeur et, bien entendu, il a élaboré la norme.

• Tout est en majuscule. Je veux dire tout, y compris les rares commentaires qu'il a faits.
• Aucune indentation.
• La dénomination des variables ressemblait à APRGNAME. A = portée de la variable, par exemple P pour public, PRG = les trois premiers caractères du fichier source qui a créé la variable, NOM = nom de la variable dans les 6 caractères restants autorisés par dBase / Clipper.
• Les 4 premières et les 4 dernières lignes du code source avaient une longueur de 80 *. Pourquoi? Il pouvait donc entendre l’imprimante à matrice de points commencer et terminer l’impression d’un fichier. La mémoire est l'ensemble du programme a été imprimé via l'ordinateur central hebdomadaire, 20 000 pages.
• Je suis sûr qu'il y en a beaucoup d'autres que j'ai réussi à vider de mon cerveau.

J'étais un tout nouveau programmeur autodidacte à ce stade, mais je savais assez pour ne pas écouter le scientifique fou et s'enfuir avant que je ne demande à reprendre le projet.

Et oui, nous avons dit à la direction à quel point ces pratiques étaient mauvaises, mais nous avons toujours eu l'habituel "payaient cet entrepreneur à un gros prix, il devait savoir de quoi il parlait".

Encore un souffle de mon passé.

Citation du propriétaire de l'entreprise:

Il n'y aura pas de code écrit à l'aide de langages d'interprétation car j'ai perdu 25 millions d'euros sur ce projet {explétif} écrit en Java.

Le projet Java était un système de négociation d’actions conçu pour traiter quelques dizaines d’actions, qui était maintenant utilisé pour traiter des milliers de personnes. Au lieu de s'attaquer aux défauts de conception ou à un matériel médiocre, l'ensemble de la société a été obligé de convertir toutes les applications non C / C ++ en C / C ++, et tous les nouveaux développements devaient se faire en C / C ++. Les langages d'interprétation signifiaient tout ce qui n'était pas compilé, et le propriétaire ne considérait que Assembler, C et C ++ compilé.

Pour une entreprise de 800 personnes, dont la majeure partie du code était en Java et en Perl, cela signifiait que toute la société passait l'essentiel de son temps au cours des deux prochaines années à réécrire du code parfaitement fin en C / C ++.

Assez drôle, une vingtaine d’années avant ce fiasco, j’étais chez une autre société dans laquelle le responsable technique avait décidé que notre logique de tri (c’était une sorte de bulle) devait être recodée en assembleur au lieu d’être remplacée par Quick Sort parce que - les algorithmes le font. pas améliorer les performances. Le seul moyen d'améliorer les performances était de réécrire la même logique dans l'assembleur.

Dans les deux cas, je suis parti peu de temps après la dictée.

Comme beaucoup de programmeurs (mais pas assez), je déteste la décoration de code. Cela me met en colère lorsque je dois utiliser un préfixe de signe dollar ($) pour les noms de variables, ou un trait de soulignement pour les variables privées, même sans getters / setters. Si vous avez besoin de décorer votre code pour le comprendre, alors vous devez sortir le diable!

Cela fait un moment que je travaille avec un système Web où tous les paramètres passés doivent être nommés P1, P2, P3, etc. Aucune chance en enfer de savoir ce qu’ils étaient sans une documentation exhaustive.

De plus, bien que n'étant pas strictement une norme de codage, dans le même système, chaque fichier devait s'appeler xyz0001.ext, xyz0002.ext, xyz0003.ext, etc., où xyz était le code de l'application en elle-même.

C'était il y a très longtemps - 1976 pour être exact. Mon chef n’avait jamais entendu parler d’Edsger Dijkstra ni lu un numéro du CACM, mais il avait entendu dire que "GOTO est mauvais", nous n’avions donc pas le droit d’utiliser GOTO dans nos programmes COBOL. C'était avant que COBOL ajoute "end if", donc à l'époque il ne disposait que de deux et demi des trois structures de contrôle classiques (sequence, if / then / else, effectuer (c'est-à-dire faire pendant)). À contrecoeur, il a autorisé GOTO dans nos programmes de base et les instructions de branche dans nos programmes de langue Assembler.

Désolé que ce soit une sorte de "tu devais être là". Autant que je sache, chaque langage inventé depuis 1976 dispose de structures de contrôle adéquates pour que vous n'ayez jamais besoin d'utiliser GOTO. Mais le fait est que le patron n'a jamais su POURQUOI GOTO était considéré comme dangereux, ou quelle langue était la maladie infantile et quelle était la maladie mortelle.

J'ai travaillé dans un projet où l'architecte en chef avait demandé d'écrire un code explicite. L'un des pires exemples que j'ai trouvés dans le code (et qu'il a approuvé avec joie) est le suivant.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Même ReSharper vous a dit que c'est faux!

Lors de mon dernier emploi, "normes" serait un terme très fort pour ce que m'a donné le type qui m'a embauché. En programmant des sites Web sous ColdFusion et SQL, on m'a donné des exigences de codage telles que:

• Ne pas utiliser comprend. J'aime une grande page
• Toujours séparer les mots dans les noms de variables et de colonnes avec des traits de soulignement (sauf isactive, prénom, etc.)
• N'utilisez jamais d'abréviations - écrivez toujours le prénom (il écrivait souvent fname et ainsi de suite)
• N'utilisez pas de noms déroutants (tels que amount_charged et charge_amount, qui mesuraient des choses différentes mais liées)
• N'utilisez pas de DIV , et utilisez un minimum de CSS - utilisez plutôt des tables imbriquées (j'ai trouvé une profondeur de six couches, une fois).
• Ne cachez aucune requête. Déjà.
• Vous allez utiliser une variable sur plus d'une page? Domaine d'application.
• Chaque page est son propre bloc try / catch. Nous n'avons pas besoin / ne voulons pas d'un gestionnaire d'erreur global.

J'ai commencé à les changer dès qu'il a arrêté.

Dans ma vie en tant que codeur C ++, deux "règles" vraiment méchantes étaient appliquées:

1. "Nous ne pouvons pas utiliser la STL, car VC ++ 4.1 ne la prend pas en charge (et nous ne pouvons pas basculer vers VC ++ 6.0 pour le moment)."
2. "N'utilisez pas QuickSort, car il peut s'agir de O (n ^ 2) dans les cas graves; utilisez cette implémentation de l'algorithme HeapSort I (nom du chef de projet supprimé) écrit en tant qu'étudiant."

Je suis obligé d'avoir une documentation XML pour toutes les classes et tous les membres de la classe. Y compris privé. Je suis encouragé à utiliser les commentaires par défaut de ghostdoc.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}