La pire norme de codage que vous ayez jamais eu à suivre?
Avez-vous déjà dû travailler à des normes de codage qui:
- Vous avez considérablement réduit votre productivité?
- Ont été initialement inclus pour de bonnes raisons, mais ont été conservés longtemps après que la préoccupation d'origine est devenue sans objet?
- Étaient-ils dans une liste si longue qu'il était impossible de tous les retenir?
- Avez-vous pensé que l'auteur essayait simplement 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 modèles de commentaires 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 réel pour le remarquer lorsque vous mettez à jour des choses. Les mauvais commentaires sont pires que pas de commentaires.
2) Souvent, ils répètent simplement des informations qui sont déjà contenues dans l'outil de contrôle de source, mais moins précises. Par exemple: Dernière modification par, liste des dates/motifs de modification.
Nous avons eu un professeur qui a demandé une fois que nous ayons 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.
La norme de codage de notre société (C #) a appelé à une utilisation intensive des #REGIONs (pour ceux qui ne le savent pas, elle marque des blocs de code source qui seront regroupés sur une seule ligne dans Visual Studio). En conséquence, vous avez toujours ouvert ce qui semblait être une classe bien structurée, seulement pour trouver des tas et des tas d'ordures balayés sous des tapis profondément imbriqués de constructions #REGION. Vous auriez même des régions autour de lignes simples, par exemple avoir à déplier une zone de dépliage 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 de la région. L'horreur. L'horreur.
Les régions sont l'une des fonctionnalités les pires jamais ajoutées à Visual Studio; il encourage la structuration de la surface plutôt que la véritable structure OO.
Aujourd'hui, je tue #REGIONs à vue.
Dans un travail, nous avons été obligés d'utiliser une forme bizarre 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 au tableau
- 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 être appelée: PRSNFRSTNMVC30X (Tableau des personnes, colonne Prénom, 30 caractères Varchar, non nul)
Insistant pour que tous les accolades soient suivies d'un commentaire sur la fin 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 ==
dit Nuff.
- Les noms des variables locales sont tous en minuscules sans soulignement
Exemples réels: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts, potentialmsceventref
The 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, pourrait être déchiffré sans espaces Word si vous le sondiez, et vous en passiez sans. […] Le latin aussi a cessé de séparer les mots au deuxième siècle. La perte est déroutante, car l'œil doit travailler beaucoup plus dur 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". "
Le chef de logiciel d’une entreprise m’a demandé de faire "simple, rendundant code ". Il était interdit, par exemple, d'ajouter un nouveau paramètre à une fonction existante. Il fallait à la place dupliquer la fonction, en laissant l'original intact pour éviter les régressions. Pas de test formel bien sûr (gaspillage de temps).
Il nous a également été interdit d'utiliser un logiciel de fusion; chaque fichier ne pouvait être modifié que par un seul programmeur à la fois. Le logiciel de contrôle des révisions était bien sûr de la science-fiction.
Le jour le plus heureux de ma vie a été son licenciement (sachez qu'il est très, très difficile de licencier quelqu'un en Italie).
Toute interaction avec la base de données doit être effectuée via procédures stockées . Cela pourrait avoir du sens si nous vivons en 1997 et non en 2010.
Je viens de réaliser que cela couvre en fait tous les critères de la question d'origine:
- Vous avez considérablement réduit votre productivité? VÉRIFIER. S'il vous plaît - utilisez simplement un ORM .
- Ont été initialement inclus pour de bonnes raisons, mais ont été conservés longtemps après que la préoccupation d'origine est devenue sans objet? VÉRIFIER. Le gestionnaire était développeur pour un serveur de base de données il y a 1000 ans et a intégré cette norme de codage.
- Étaient-ils dans une liste si longue qu'il était impossible de tous les retenir? VÉRIFIER. Cela comprenait "autant de logique que possible devrait être stockée dans la base de données".
- Avez-vous pensé que l'auteur essayait simplement de laisser sa marque plutôt que d'encourager de bonnes pratiques de codage? VÉRIFIER. Revient toujours au gestionnaire en tant qu'ancien 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 parce que le CTO pensait que "nous" pouvions le faire mieux et plus rapidement. Même les constructions de base comme les listes et la classe de chaînes.
Notation hongroise
Exemple extrait de " explication de Charles Simonyi de la convention de dénomination des identificateurs de notation hongroise " sur MSDN.
1 #inclut "sy.h"
2 extern int * rgwDic;
3 extern int bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 wHash non signé = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 for (; * pbsy! = 0; pbsy = & psy -> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 while (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 return (psy);
27}
28}
29 cwSz = 0;
30 if (cch> = 2)
31 cwSz = ( cch-2/sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) -rgwDic;
33 zéro ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 return (psy) ;
36}J'ai déjà travaillé sur un projet dans lequel le chef de projet exigeait que chaque variable - CHAQUE variable - soit préfixée par "v". Ainsi, vCount, vFirstName, vIsWarranty, etc.
Pourquoi? "Parce que nous travaillons dans VBScript et que tout est de toute façon une variante".
WTF.
Presque oublié celui-ci:
Citation d'un manager:
Ne corrigez pas ou ne documentez pas les bogues 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é des années après. Cela peut sembler trivial, mais essayer d'ignorer les bogues est plus difficile que de les trouver.
Commentaires XML appliqués sur toutes les méthodes, constantes, énumérations et propriétés non privées.
Cela a conduit à du code assez encombré, d'autant plus que le résultat final était que les gens frappaient juste /// pour créer un talon de commentaire vide pour tout ou installaient GhostDoc et lui 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'a été appliquée d'aucune façon et a abouti à la création de beaucoup d'encombrement dans les fichiers de code . Il existe de meilleures façons de créer des documents de code significatifs que les exigences de génération aveugles "doivent avoir un commentaire".
Pas vraiment une norme de codage, mais nous avions un fichier dans le contrôle de source appelé 'changelog.txt'
Chaque fois que vous effectuez une consignation, vous devez ajouter manuellement une entrée à ce fichier. Cette entrée était le numéro de révision de Subversion et votre commentaire de consignation.
Lorsque le nouveau CTO a commencé et que quelqu'un lui a dit cela, il a rapidement pris une décision exécutive et a dit: "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é douloureusement conservé dans les fichiers via un code commenté.
Le gros problème que j'ai trouvé avec cela est que vous n'aviez souvent aucune idée de la raison pour laquelle le code a été commenté. Était-ce parce qu'un développeur apportait activement des changements et voulait le garder pour référence ou n'était-il plus nécessaire?
La pire norme de codage à laquelle j'ai jamais participé est des bases de code qui n'en avaient pas du tout. Je préfère suivre une norme de codage avec laquelle je suis totalement en désaccord que de travailler dans des bases de code où il n'y en a pas du tout. Cela rend d'autant plus difficile l'apprentissage de nouvelles parties de la base de code.
Forcer les commentaires en ligne pour le contrôle de version était 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 a insisté sur l'utilisation correcte des espaces blancs tout en `` maintenant '' une base de données avec une table très contestée qui avait plus de 200 champs et 40 déclencheurs arrive à son terme.
J'ai fait des révisions de code sur un projet dirigé par un premier temporisateur C++ qui a décidé que toutes les fonctions des membres de la classe devraient être préfixées avec le nom de la classe et la visibilité:
class MyClass
{
public:
void MyClass_Public_setValue(int value);
}
J'ai eu un travail il y a des années où tout notre code devait être aligné à gauche - sans retrait. Le gars qui a élaboré cette politique n'a pas aimé avoir à faire défiler horizontalement en regardant de longues lignes de code, ce qui équivaut à jouer au ping-pong avec ses yeux.
Être obligé d'indenter tout le code de quatre espaces;)
Un souffle de plus de mon passé.
Citation du propriétaire de l'entreprise:
Il n'y aura pas de code écrit en utilisant des langages d'interprétation car j'ai perdu 25 millions sur ce projet {explétif} écrit en Java.
Le projet Java était un système de négociation d'actions conçu pour gérer quelques dizaines de stocks, qui était maintenant utilisé pour en traiter des milliers. Au lieu de remédier aux défauts de conception ou à un matériel médiocre, toute l'entreprise a été contrainte de convertir toutes les applications non C/C++ en C/C++, et tous les nouveaux développements devaient être en C/C++. Les langages d'interprétation signifiaient tout ce qui n'était pas compilé, et le propriétaire ne considérait que les assembleurs, C et C++ compilés.
Pour une entreprise de 800 personnes, dans laquelle la plupart du code était en Java et Perl, cela signifiait que toute l'entreprise passait la plupart 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 dans une autre entreprise dans laquelle le responsable technique a décidé que notre logique de tri (c'était un Bubble Sort) devait être recodée en assembleur au lieu d'être remplacée par Quick Sort car - - Les algorithmes n'améliorent pas les performances. La seule façon 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.
C'est plus un exemple de la façon dont ne pas avoir de normes de codage peut nuire.
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 a été écrite en dBase/Clipper dont il était le seul développeur et bien sûr, il est venu avec la norme.
- Tout est en majuscule. Je veux dire tout, y compris les rares commentaires qu'il a faits.
- Aucune indentation.
- La dénomination variable était quelque chose comme APRGNAME. A = étendue de la variable, par exemple P pour public, PRG = trois premiers caractères du fichier source qui a créé la variable, NAME = nom de la variable dans les 6 caractères restants autorisés par dBase/Clipper.
- Les 4 premières et 4 dernières lignes du code source mesuraient 80 * de long. Pourquoi? Il pouvait donc entendre l'imprimante matricielle commencer et terminer l'impression d'un fichier. La mémoire est l'ensemble du programme a été imprimé via l'hebdomadaire mainframe, 20 000 pages.
- Je suis sûr qu'il y en avait beaucoup d'autres que j'ai réussi à vider de mon cerveau.
J'étais un tout nouveau programmeur autodidacte à ce stade, mais j'en savais assez pour ne pas écouter le savant fou et foutre le camp avant de demander de reprendre le projet.
Et oui, nous avons dit à la direction à quel point ces pratiques étaient mauvaises, mais nous avons toujours eu l'habitude "de payer le gros prix à cet entrepreneur, il doit savoir de quoi il parle".
Comme beaucoup de programmeurs (mais pas assez), je déteste la décoration de code. Cela me rend furieux quand je dois utiliser un préfixe de signe dollar ($) pour les noms de variable, ou des traits 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 de l'enfer!
C'était il y a longtemps - 1976 pour être exact. Mon patron n'avait jamais entendu parler d'Edsger Dijkstra ni lu un numéro de CACM, mais il avait entendu une rumeur quelque part selon laquelle "GOTO est mauvais", nous n'étions donc pas autorisés à utiliser GOTO dans nos programmes COBOL. C'était avant que COBOL ajoute le "end if", donc à l'époque il n'avait que deux et demi des trois structures de contrôle classiques (séquence, if/then/else, perform (c'est-à-dire do while)). Il a autorisé à contrecœur GOTO dans nos programmes de base et les instructions de branchement dans nos programmes de langage assembleur.
Désolé que ce soit une sorte d'histoire "tu devais être là". Pour autant que je sache, chaque langue inventée depuis 1976 a des 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 nocif, ou quelle langue était le trouble infantile et quelle était la maladie mortelle.
J'ai travaillé dans un projet où l'architecte en chef exigeait d'écrire (trop) du code explicite. L'un des pires exemples que j'ai trouvés dans le code (et il a joyeusement approuvé) était 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'était faux!
Je travaille avec un système Web depuis un certain temps où tous les paramètres transmis devaient être nommés P1, P2, P3 etc. Aucune chance en enfer de savoir à quoi ils servent sans une documentation complète.
En outre - bien que n'étant pas strictement une norme de codage - dans le même système, chaque fichier devait être nommé xyz0001.ext, xyz0002.ext, xyz0003.ext, etc. - où xyz était le code de l'application en soi.
Lors de mon dernier emploi, les "normes" seraient un terme très fort pour ce que m'a donné le gars qui m'a embauché. Programmation de sites Web en ColdFusion et SQL, on m'a donné des exigences de codage comme:
- N'utilisez pas d'includes. J'aime une grande page
- Séparez toujours les mots dans les noms de variables et de colonnes avec des traits de soulignement (sauf isactif, prénom, etc.)
- N'utilisez jamais d'abréviations - écrivez toujours le prénom (il écrivait fréquemment fname et ainsi de suite)
- N'utilisez pas de noms déroutants (comme amount_charged et charge_amount, qui mesuraient des choses différentes mais liées)
- N'utilisez pas DIVs , et utilisez un minimum CSS - utilisez des tables imbriquées à la place (j'ai trouvé six couches en profondeur, une fois) .
- Ne cachez aucune requête. Déjà.
- Vous allez utiliser une variable sur plusieurs pages? Champ d'application.
- Chaque page est son propre bloc try/catch. Nous n'avons pas besoin/ne voulons pas d'un gestionnaire d'erreurs global.
J'ai commencé à les changer dès qu'il a quitté.
Presque toute sorte de convention de dénomination de variable qui réitère le type de variable, la mutabilité, la portée/classe de stockage et/ou leur référence. Fondamentalement, toute construction intrinsèque au langage. Cela n'est plus nécessaire au 21e siècle avec les IDE modernes (et à mon avis, à l'origine, je n'ai résolu que la mauvaise mise en page/pratiques de code). Cela inclut la notation hongroise et ses variantes:
- bigBlobStr - Une chaîne.
- bigBlobStrCurLocPtr - Un pointeur vers "l'emplacement actuel" dans ladite chaîne.
- someIntArray - Tableau d'entiers
ou des choses comme:
- e_globalHeading - Variable externe
- sg_prefPoolSz - Variable globale statique
et bien sûr une des plus horribles atteintes oculaires de la POO, m_ pour tous les membres. Si vous ne pouvez pas être sûr/garder une trace des variables locales, membres, globales, statiques ou finales/const, vous pourriez écrire mal clair , code de spaghetti mal factorisé.
C'est tout à fait différent de la spécification d'une convention préfixe/suffixe pour des choses comme min, max, moy, taille, nombre, index, et cetera, ce qui est bien.
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 ghostdoc par défaut.
public class User
{
/// <summary>
/// the _userID
/// </summary>
private int _userID;
}
Le pire standard auquel j'ai jamais été confronté:
StyleCop pour C #
Prenez toutes les normes inutiles et mettez-les dans un outil qui s'exécute au moment de la compilation plutôt que dans le IDE au moment de la conception).
//this is not a legal comment.
// nor is this
// doit être suivi d'un seul espace, si vous déboguez, utilisez //// pour commenter le code. Les propriétés doivent également avoir des commentaires "triple barre oblique" et elles doivent lire "Obtient ou définit xxxxx" avec un point à la fin et correctement capitalisé.
Pouah. Peut-être qu'il y a un point avec des API largement publiées, mais mon bœuf principal est qu'elles auraient sûrement pu le construire comme un plugin à la R #.
J'ai travaillé pendant une courte période au Japon. Je faisais du codage mathématique complexe. La norme de codage de l'entreprise devait n'avoir absolument aucun commentaire. C'était difficile car j'aurais aimé ajouter quelques commentaires pour expliquer les calculs complexes et ne pas m'oublier après quelques semaines. Dommage que le prochain gars qui vient après moi comprenne ce que faisait le code.
C'était la première fois que je voyais que les commentaires de codage étaient interdits.
Lors d'un travail précédent, la norme C # devait avoir au moins deux espaces entre le nom de type et le nom de variable dans les déclarations, le nom de la méthode doit commencer sur la ligne suivante des modificateurs d'accès et renvoyer le type, un espace doit se produire avant toute ponctuation ouverte (parenthèse ou parenthèse), toutes les déclarations de variables au début de la méthode, les déclarations distinctes de l'affectation et l'indentation était de 3 espaces. Exemple:
private static int
ThisIsTheMethod (int code, string message)
{
int i;
int j;
int k;
for (i = 0; i < message.Length; i++)
{
if (message [i] == '!') return -1;
}
j = SomeMethod (code);
k = OtherMethod (j);
return k;
}
Bien que moche, il était réalisable à l'exception que Visual Studio ne voulait vraiment pas les choses de cette façon et c'était plus une étape supplémentaire après le codage "normalement" pour le reformater comme ceci.
à mon travail précédent, que j'ai quitté avec plaisir il y a 3 mois:
base de données:
- Les noms de table devaient être en majuscules.
- Les noms de table devaient être préfixés TBL_
- Les champs devaient être préfixés: DS_ (pour varchar, ce qui n'avait aucun sens) NU_ pour les nombres CD_ pour ("champs de bits") DT_ pour les dates
- les champs de la base de données devaient également être en majuscules [CD_ENABLED]
- idem avec les noms sp [SP_INFINITY_USER_GROUPS_QRY] et les noms de base de données [INFINITY]
- ai-je mentionné que les noms sp étaient en fait comme ça? Préfixe SP_, puis nom de la base de données SP_INFINITY_ puis nom de la table, SP_INFINITY_USER_GROUPS puis ce que le sp devait réellement faire (QRY, UPD, DEL, INS) jésus, ne me lancez même pas sur des requêtes qui ne sont pas uniquement des requêtes CRUD.
- tous les champs de texte devaient être varchar (MAX), sans équivoque.
- les nombres étaient soit int, soit doubles, même si vous auriez pu utiliser un autre type.
- les champs "booléens" (bit) étaient int, sans raison.
- les procédures stockées devaient être préfixées sp_productname_
asp.net/c #/javascript
- CHAQUE fonction unique devait être enveloppée dans try {} catch {}, afin que les applications ne "explosent" pas (du moins c'était la raison officielle), même lorsque cela produisait des choses qui ne fonctionnaient pas et sans avoir la moindre idée pourquoi.
- les paramètres doivent être préfixés par p, par exemple pCount, pPage
- les variables de portée devaient être préfixées par w (comme dans "working", qu'est-ce que ça veut dire?)
- statique avec g, etc.
- tout le post-framework 1.1 était hors limites, comme vous aviez de toute façon de réelles utilisations pour linq et les génériques. (J'ai fait un point pour les forcer à me laisser utiliser jquery cependant, j'ai réussi à cela, au moins).
Inclusion obligatoire, expansion des informations $ Log $ lorsque notre SCC était une version désuète de PVCS. Nous avions certains fichiers où les informations $ Log $ étaient beaucoup, beaucoup plus longues que le code réel du fichier.
Toutes les sorties dans un script PHP doivent être reprises ligne par ligne.
<?php
echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";
?>
(Avertissement: je n'ai pas eu à le suivre, mais une équipe avec laquelle j'ai travaillé l'a fait.)
Le pire était un projet (C++) où les classes étaient préfixées avec les abréviations des modules.
Par exemple, si quelque chose se trouvait dans le module MessagePassing et faisait partie du mécanisme de réponse, il pourrait être appelé MESPAS_RESSomeobject.
Travailler sur ce code m'a donné envie de me creuser les yeux.
Pas le pire, mais mon travail actuel nécessite un c_ préfixes sur les classes et e_ préfixes pour les énumérations. Rien pour les structures. mais _t suffixe sur les typedefs. C'est assez moche aussi.
Oh, et les commentaires d'en-tête de fonction dans les deux .h et .cpp (déclaration et définition) qui bien sûr ne correspondent presque jamais.
Mon préféré est la règle "Pas de nombres magiques" appliquée sans la moindre idée. Par exemple, j'ai vu une fois un commentaire dans une revue de code indiquant que la règle "Pas de nombres magiques" avait été violée par cette ligne de code:
if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )
Je suppose que le critique voulait une constante au lieu de 2, comme #define TWO 2
Les noms de nos méthodes devaient être au format "Get/Set/Add/Delete" + nom de l'objet cible + noms de tous les paramètres.
GetUserById(userId);
InsertUser(user);
DeleteUser(user);
Assez juste - mais la règle est très stricte. Les types d'objets complexes n'étaient pas autorisés à être abrégés, et les opérations devaient toujours répertorier chaque paramètre de demande, aussi ridicule soit-il:
GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus(...
Après avoir ajouté les noms de variables complets (qui n'étaient pas autorisés à être raccourcis non plus), vous pouvez imaginer la durée de certains appels de méthode simples. Mot enveloppant.
Là où je travaille maintenant, le processus de nommage des variables pour tout ce qui concerne la base de données est:
- $ sql pour les relevés
- $ result pour les résultats de la requête
Ce qui est logique, cependant, lorsque j'ai évoqué le fait que la convention était trop générique et que cela se terminerait par un chevauchement des variables, la réponse était "use result_alt or sql_alt". Mes sentiments en commentant, si vous utilisiez des noms de variables appropriés qui signifient le but, vous n'auriez pas besoin de commentaires ou autant de commentaires.
La pire norme de codage que j'ai jamais eu à suivre était "Tous les noms de variables d'objet doivent être préfixés par" obj "". C'était sur un grand Java, donc presque tout était un objet. Le pire était que presque tout le monde a adopté une politique de nommage des variables en ajoutant simplement "obj" au nom de la classe. Nous avons fini avec des trucs comme Person objPerson1 tout au long du code. Je me suis opposé une fois, et j'ai demandé à l'un des autres développeurs d'interpréter qu'elle aimait la convention "parce que je n'ai plus à penser à mes noms de variables". Cet endroit était un véritable spectacle d'horreur ...
Peut-être la norme de codage de Huawei Software Company. Ils veulent que vous déclariez tous les membres publics :))
Écrire quoi que ce soit dans Fortran ( WATFOR , FORTRAN 77 ) où un caractère non blanc dans la colonne 1 était un commentaire, et le compilateur ne vous avertissait pas si vous alliez au-delà de la colonne 72, il l'ignorerait silencieusement.
Au moins, je n'ai passé que sept ans à faire ça.
Avoir ce qui équivalait à des fichiers d'en-tête C, dans un projet Java.
Les interfaces existent pour de bonnes raisons, mais cette norme a rendu obligatoire une interface (foo.Java) pour chaque classe (fooImpl.Java) que cela ait un sens ou non. Beaucoup de choses à garder synchronisées, interruption complète du clic dans la méthode Eclipse, travail occupé inutile.
Le système de construction l'a appliqué, mais je ne peux pas imaginer quel était le but initial. Heureusement, nous l'avons abandonné pour un nouveau code lorsque nous sommes passés à un nouveau système de contrôle de version et de construction, mais il en reste encore beaucoup.
En même temps, nous avons également abandonné l'habitude stupide de contrôle de version-info-dans-fichier-commentaires qui était obligatoire.
Je travaille actuellement dans une entreprise où les requêtes SQL sont effectuées via quelque chose appelé "Request Class". C'est ridicule:
Dans "include/request.class.php"
class RequestClass
{
// ... some code.
public function getUser($where)
{
global $initrequest
$sql = $initrequest['users']
$sql.= $where;
return execute($sql);
}
}
Dans initrequest.php:
$initrequest['users'] = 'SELECT * FROM users WHERE ';
Et il a été appelé à partir de l'application de cette façon:
$request = new request();
$tmpquery = "username = $username AND password = $password";
$request->getUsers($tmpquery);
Et ils ont un système de modèle similaire basé sur des "blocs", mais après avoir compris ce que je montre ici, j'ai continué à appuyer pour mettre à la corbeille tout notre logiciel et le réécrire dans Symfony.
Pas plus d'une ligne de code autorisée dans Main ()
Un professeur de mon université qui a eu la chance de ne pas avoir insisté pour que ses étudiants juniors en C # ne soient pas autorisés à mettre plus d'une ligne de code dans le point d'entrée de leurs applications console.
Cela a un sens raisonnable lors du développement d'une application professionnelle, mais lorsque la seule intention du programme est de prendre quelques entrées de base et de produire une seule sortie (c'est-à-dire MultiplyTwoNumbers.exe), une telle exigence est plus douloureuse que bonne.
En plus de la "ligne de code principale", le professeur a également insisté sur le fait que chaque ligne de code a un commentaire descriptif et que chaque membre de la classe a un verbeusement nom descriptif. Des points perdus si le professeur ne sentait pas que ces exigences avaient été remplies "de manière adéquate".
Les étudiants forcés de s'en tenir à ces règles étaient (presque) tous des débutants en programmation et je peux donc voir la valeur de l'application de conduites telles que la bonne appellation et la séparation des préoccupations. Malgré cela, en tant que tutrice .NET dans mon université, j'aidais constamment ses étudiants à répondre à ces exigences banales et odieuses longtemps après avoir obtenu leur code travail.
À mon avis, lorsque l'on éduque quelqu'un qui est tout nouveau à un langage de programmation, la première préoccupation devrait être de savoir comment créer du code, pas comment créer basé sur des normes code.
Msgstr "N'utilisez pas le style de commentaire C++ pour le code C".
Bien que cela puisse encore avoir une petite valeur s'il existe un risque de devoir porter votre programme sur un compilateur obsolète, ce n'est généralement qu'un problème. Ma plus grande objection est qu'il est très difficile à utiliser /* pour bloquer le commentaire d'une grande région pendant le développement ou les tests unitaires. */
Mon conférencier ADA à uni a insisté sur le fait que chaque méthode avait un commentaire décrivant les conditions préalables, les postconditions et le grand O. Le plus gros problème avec cela était qu'il n'a jamais pris la peine d'expliquer ce que signifiait réellement le grand O et n'a jamais vérifié si elles étaient correctes, alors je me suis retrouvé à copier et coller ce bloc de commentaires des centaines de fois.
-- Method_Name
-- PRECONDITIONS: none
-- POSTCONDITIONS: none
-- O(n) = n
(C++)
Toutes les valeurs de retour devaient être HRESULTS (les valeurs standard - pas les résultats définis par l'utilisateur)
C'était il y a quelques années seulement. Les personnes âgées étaient encore tellement passionnées par COM et elles n'ont jamais lu ou appris d'autres meilleures pratiques. C'était un environnement incroyablement fermé.
Le même endroit ne permettait pas non plus d'utiliser STL.
Je suis parti peu de temps après avoir découvert cette friandise.
Dans Visual Basic 6. , nous avons dû ajouter des blocs de gestion des erreurs à chaque méthode. Aucune exception. Nous l'avons donc fait.
Ensuite, nous avons dû expliquer pourquoi certaines parties de l'application étaient lentes.
L'espace limité pour les noms de variables/objets est probablement ma plus grande irritation. J'ai travaillé dans un langage propriétaire relativement moderne qui n'autorise que 10 caractères. Il s'agit d'un maintien de ses versions originales.
Le résultat net est que vous vous retrouvez avec des conventions de nommage drôles définissant ce que chaque personnage de votre 10 autorisé doit représenter. Quelque chose comme:
- 1-3: préfixe d'application
- 4-6: préfixe du module
- 7-9: section définie par l'utilisateur
- 10: un nombre juste au cas où deux ... ou 9 sont nommés la même chose.
Mon préféré devrait être les directives de dénomination de la base de données que nous essayons actuellement de respecter. Toutes les tables utilisées pour les relations plusieurs-plusieurs doivent être nommées en utilisant les noms des tables liées et doivent être suffixées avec "Link". Et bien sûr, pas de pluralisation des noms de table.
- OrderLines? Nan. Il devrait s'appeler OrderProductLink
- Copains? Nan. Il doit s'agir de PersonPersonLink
Être obligé d'ajouter une description de fichier dans chaque fichier (c'est un projet C # ).
// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
// Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
// The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------
Dans une entreprise, nous avons dû rédiger une documentation technique expliquant comment nous allons écrire une fonctionnalité. Il est rapidement devenu obsolète puisque vous ne pensez pas à tout lorsque vous programmez en UML.