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

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?

Nous commençons par

• Directives .NET de Microsoft: http://msdn.microsoft.com/en-us/library/ms229042.aspx (lien mis à jour pour .NET 4.5)
• Directives C # de Microsoft: http://blogs.msdn.com/brada/articles/361363.aspx .

puis documentez les différences et les ajouts à cette base de référence.

IDesign a un document de normes de codage C # qui est couramment utilisé. Voir également les Framework Design Guidelines 2nd Ed .

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.

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.

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.

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.

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

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.

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;)

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

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/

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.

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 .....

Règles SSW

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

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.

J'ai récemment trouvé le manuel Encodo C # , qui comprend des idées provenant de nombreuses autres sources (IDesign, Philips, MSDN).

Une autre source peut être Professional C # / VB .NET Coding Guidelines .

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.

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

Voir ceci: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

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

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 .

Vous pouvez consulter ceci, Top 7 des normes de codage et des documents d'orientation pour les développeurs C # / .NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html espérons que cela vous aidera

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 :)

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é).

Je suis également Resharper. Aussi la ligne de guidage mentionnée sur le blog de scott guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx et http://csharpguidelines.codeplex.com/releases/view/46280

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 ;-)