Y a-t-il des suggestions pour développer un document sur les normes / bonnes pratiques de codage C #? [fermé]

159

Je suis récemment diplômé en IA (environ 2 ans) travaillant pour une opération modeste. C'est à moi (principalement comme je suis le premier «adoptant» du département) de créer un document de normes de codage C # de base (lu utile?).

Je pense que je devrais expliquer que je suis probablement l'ingénieur logiciel le plus débutant, mais j'ai hâte d'accomplir cette tâche car j'espère pouvoir produire quelque chose à moitié utilisable. J'ai fait une recherche assez approfondie sur Internet et lu des articles sur ce qu'un document de normes de codage devrait / ne devrait pas contenir. Cela semble être un bon endroit pour demander des suggestions.

Je me rends compte que j'ouvre potentiellement la porte à tout un monde de désaccords sur «la meilleure façon de faire les choses». Je comprends et respecte à la fois le fait indéniable que chaque programmeur a une méthode préférée pour résoudre chaque tâche individuelle, par conséquent je ne cherche pas à écrire quelque chose d'aussi radicalement proscriptif que d'étouffer le flair personnel mais d'essayer d'obtenir une méthodologie générale et d'accord normes (par exemple les conventions de dénomination) pour aider à rendre le code des individus plus lisible.

Alors voilà ... des suggestions? Du tout?

TK.
la source

Réponses:

26

Ironiquement, l'établissement des normes réelles sera probablement la partie la plus facile.

Ma première suggestion serait d'obtenir des suggestions des autres ingénieurs sur ce qui, selon eux, devrait être couvert et sur les lignes directrices qui, à leur avis, sont importantes. L'application de tout type de directives nécessite un certain degré d'adhésion de la part des gens. Si vous déposez soudainement un document sur eux qui spécifie comment écrire du code, vous rencontrerez une résistance, que vous soyez le plus jeune ou le plus âgé.

Une fois que vous avez un ensemble de propositions, envoyez-les à l'équipe pour commentaires et examen. Encore une fois, incitez les gens à y adhérer.

Il se peut que des pratiques de codage informelles soient déjà adoptées (par exemple, préfixer les variables membres, les noms de fonctions camelcase). Si cela existe et que la plupart des codes s'y conforment, il faudra alors formaliser son utilisation. Adopter une norme contraire causera plus de chagrin qu'il n'en vaut la peine, même si c'est quelque chose de généralement recommandé.

Il vaut également la peine d'envisager de refactoriser le code existant pour répondre aux nouvelles normes de codage. Cela peut sembler une perte de temps, mais avoir un code qui ne répond pas aux normes peut être contre-productif car vous aurez un méli-mélo de styles différents. Cela laisse également les gens dans un dilemme si le code dans un certain module doit être conforme à la nouvelle norme ou suivre le style de code existant.

Andrew Grant
la source
14

J'ai toujours utilisé le pdf de Juval Lowy comme référence lors de l' élaboration des normes / meilleures pratiques de codage en interne. Il suit de très près FxCop / Source Analysis , qui est un autre outil précieux pour s'assurer que la norme est respectée. Entre ces outils et ces références, vous devriez être en mesure de proposer une norme intéressante que tous vos développeurs ne craindront pas de suivre et de pouvoir les appliquer.

Dale Ragan
la source
9

Les autres affiches vous ont pointé vers la ligne de base, tout ce que j'ajouterais est de rendre votre document court, doux et précis, en utilisant une forte dose de Strunk and White pour distinguer le "must have" du "it serait bien si ".

Le problème avec les documents de normes de codage est que personne ne les lit vraiment comme ils le devraient, et lorsqu'ils les lisent, ils ne les suivent pas. La probabilité qu'un tel document soit lu et suivi varie inversement avec sa longueur.

Je suis d'accord que FxCop est un bon outil, mais trop de cela peut prendre tout le plaisir de la programmation, alors soyez prudent.


la source
9

N'écrivez jamais vos propres standards de codage en utilisant ceux MS (ou ceux de Sun ou ... selon votre langue). L'indice est dans le mot standard, le monde serait un endroit beaucoup plus facile à coder si chaque organisation n'avait pas décidé d'écrire la sienne. Qui pense vraiment qu'apprendre un nouvel ensemble de «normes» chaque fois que vous changez d'équipes / projets / rôles est une bonne utilisation du temps de n'importe qui. Le plus que vous devriez faire est de résumer les points critiques, mais je vous déconseille même de faire cela car ce qui est critique varie d'une personne à l'autre. Deux autres points que je voudrais faire sur les normes de codage

  1. Fermer suffit - Changer le code pour suivre les normes de codage à la lettre est une perte de temps tant que le code est suffisamment proche.
  2. Si vous changez de code que vous n'avez pas écrit, suivez les «normes de codage locales», c'est-à-dire que votre nouveau code ressemble au code environnant.

Ces deux points sont la réalité de mon souhait que tout le monde écrive un code qui se ressemblait.

David Hayes
la source
8

J'ai trouvé la documentation suivante très utile et concise. Il provient du site idesign.net et il est écrit par Juval Lowy

Norme de codage C #

NB: le lien ci-dessus est maintenant mort. Pour obtenir le fichier .zip, vous devez leur donner votre adresse e-mail (mais ils ne l'utiliseront pas pour le marketing ... honnêtement) Essayez ici

Abel Gaxiola
la source
5

Je viens de commencer à un endroit où les normes de codage imposent l'utilisation de m_ pour les variables membres, p_ pour les paramètres et les préfixes pour les types, tels que «str» pour les chaînes. Donc, vous pourriez avoir quelque chose comme ça dans le corps d'une méthode:

m_strName = p_strName;

Horrible. Vraiment horrible.

demoncodemonkey
la source
1
IntelliSense dans Visual Studio 2010 vous permet de taper «Nom» et il correspondra à la sous-chaîne dans p_strName- le rend 10% moins douloureux lorsque vous êtes obligé de travailler avec une telle abomination. : o
Sam Harwell
5

J'ajouterais Code Complete 2 à la liste (je sais que Jeff est un peu fan ici) ... Si vous êtes un développeur junior, le livre est pratique pour configurer votre esprit d'une manière qui jette les bases du meilleur il existe des pratiques d'écriture de code et de création de logiciels.

Je dois dire que j'y suis arrivé un peu tard dans ma carrière, mais cela régit de nombreuses façons dont je pense au codage et au développement de cadres dans ma vie professionnelle.

Cela vaut le détour;)

samiq
la source
2
J'étais sur le point de proposer le même livre. À lire absolument.
Pascal Paradis
Je suis en train de lire le livre, lu> 67%. Cela a changé la façon dont j'envisage la programmation. Doit lire.
UrsulRosu
4

Les propres règles de Microsoft sont un excellent point de départ. Vous pouvez les appliquer avec FxCop.

Keith
la source
4

Je serais tenté d'appliquer le StyleCop de Microsoft comme norme. Il peut être appliqué au moment de la construction. mais si vous avez du code hérité, appliquez simplement StyleCop sur le nouveau code.

http://code.msdn.microsoft.com/sourceanalysis

Finalement, il aura une option de refactorisation pour nettoyer le code.

http://blogs.msdn.com/sourceanalysis/


la source
2
Vous n'êtes peut-être pas d'accord avec tout ce qui est appliqué par StyleCop, mais considérez que Microsoft s'oriente vers une norme unique, telle qu'elle est appliquée par StyleCop - il s'agit donc d'un ensemble de normes que vous pouvez vous attendre à ce que d'autres développeurs connaissent. La cohérence avec une grande partie du reste de l'industrie pourrait être précieuse.
Bevan
4

Personnellement, j'aime celui qu'IDesign a mis en place. Mais ce n'est pas pour ça que je poste ...

La difficulté dans mon entreprise était de prendre en compte toutes les langues. Et je sais que mon entreprise n'est pas seule à ce sujet. Nous utilisons C #, C, assembly (nous fabriquons des périphériques), SQL, XAML, etc. Bien qu'il y ait des similitudes dans les standards, chacun est généralement géré différemment.

De plus, je pense que des normes de niveau supérieur ont un impact plus important sur la qualité du produit final. Par exemple: comment et quand utiliser les commentaires, lorsque des exceptions sont obligatoires (par exemple, des événements déclenchés par l'utilisateur), si (ou quand) utiliser des exceptions par rapport aux valeurs de retour, quelle est la manière objective de déterminer ce que devrait être le code du contrôleur par rapport au code de présentation, etc. Ne vous méprenez pas, des normes de bas niveau sont également nécessaires (le formatage est important pour la lisibilité!) J'ai juste un biais envers la structure globale.

Un autre élément à garder à l'esprit est l'adhésion et l'application. Les normes de codage sont excellentes. Mais si personne n'est d'accord avec eux et (probablement plus important) personne ne les applique, alors tout est pour rien.

derGral
la source
4

Comme j'ai écrit à la fois celui publié pour Philips Medical Systems et celui publié sur http://csharpguidelines.codeplex.com, je suis peut-être un peu partial, mais j'ai plus de 10 ans d'expérience dans l'écriture, la maintenance et la promotion des normes de codage. J'ai essayé d'écrire le CodePlex en gardant à l'esprit les différences d'opinions et j'ai passé la majeure partie de l'introduction sur la façon de gérer cela dans votre organisation particulière. Lisez-le et faites-moi part de vos commentaires .....

Dennis Doomen
la source
J'aime VRAIMENT ce guide et je pense qu'il suit un format fantastique (version rapide et version complète comme beaucoup de gens que j'ai vu utiliser). Vous obtenez mon vote contre tous les autres, beau travail. Je recommande vivement d'utiliser ce document sur Codeplex comme un début car c'est un très bon guide pour comparer les notes ou suivre de près.
atconway
J'ai vu ça. Je le pense vraiment, continuez votre bon travail et je recommande ce guide au moins comme point de départ pour les développeurs .NET sérieux.
atconway
1
+1 pour le grand travail, j'aimerais pouvoir +100. C'est bref, donc les gens le liront réellement - il gagne donc les normes Microsoft et IDesign. Il a des noms de règles significatifs, une feuille de triche, des fichiers de style pour VS / R # ... il manque peut-être des exemples plus détaillés dans une feuille de triche :)
Victor Sergienko
2

Règles SSW

Il comprend des normes C # + beaucoup plus ... principalement axé sur les développeurs Microsoft

Adam Cogan
la source
1

Vous êtes probablement configuré pour échouer. Bienvenue dans l'industrie.

Je ne suis pas d'accord - tant qu'il crée le document, le pire qui puisse arriver, c'est qu'il soit oublié de tout le monde.

Si d'autres personnes ont des problèmes avec le contenu, vous pouvez leur demander de le mettre à jour pour montrer ce qu'ils préfèrent. De cette façon, c'est hors de votre assiette, et les autres ont la responsabilité de justifier leurs changements.

Adam V
la source
Je ne suis pas d'accord. Le pire qui puisse arriver est que les lignes directrices ne sont pas cohérentes; et les bugs passent. S'il est en train d'écrire un logiciel de contrôle pour le LHC, alors nous sommes fâchés. / Sarcasm
TraumaPony
1

Je suis un grand fan du livre de Francesco Balena " Practical Guidelines and Best Practices for VB and C # Developers ".

Il est très détaillé et couvre tous les sujets essentiels.Il ne vous donne pas seulement la règle, mais explique également la raison de la règle, et fournit même une anti-règle où il pourrait y avoir deux meilleures pratiques opposées. Le seul inconvénient est qu'il a été écrit pour les développeurs .NET 1.1.

urini
la source
1

L'ensemble de notre norme de codage se lit à peu près «Utiliser StyleCop».

John Kraft
la source
1

Je dois suggérer le document dotnetspider.com .
C'est un excellent document détaillé qui est utile partout.

la_drow
la source
1

J'ai déjà utilisé Juval et c'est fini sinon exagéré, mais je suis paresseux et maintenant je me conforme à la volonté de Resharper .

Kenny
la source
0

Je pense que je fais écho aux autres commentaires ici selon lesquels les lignes directrices des États membres déjà liées sont un excellent point de départ. Je modélise mon code en grande partie sur ceux-ci.

Ce qui est intéressant car mon manager m'a dit par le passé qu'il n'était pas trop attaché à eux: D

Vous avez une tâche amusante devant vous mon ami. Bonne chance et demandez si vous avez besoin de plus :)

Rob Cooper
la source
0

La norme de Philips Medical Systems est bien rédigée et suit principalement les directives de Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Mes standards sont basés sur ceci avec quelques ajustements et quelques mises à jour pour .NET 2.0 (le standard Philips est écrit pour .NET 1.x donc est un peu daté).

Joe
la source
0

Dans le code que j'écris, je suis généralement les directives de conception .NET Framework pour les API exposées publiquement et les directives de codage mono pour la casse et l'indentation des membres privés . Mono est une implémentation open source de .NET, et je pense que ces types connaissent leur métier.

Je déteste la façon dont le code Microsoft gaspille de l'espace:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

Ce que vous pourriez trouver étrange dans les directives Mono, c'est qu'elles utilisent des onglets à 8 espaces. Cependant, après un peu de pratique, j'ai trouvé que cela m'aide en fait à écrire du code moins emmêlé en imposant une sorte de limite d'indentation.

J'aime aussi la façon dont ils mettent un espace avant d'ouvrir les parenthèses.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Mais s'il vous plaît, n'appliquez rien de tel si vos collègues ne l'aiment pas (sauf si vous êtes prêt à contribuer à Mono ;-)

Dan Abramov
la source