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

StackOverflow https://stackoverflow.com/questions/14967

  •  08-06-2019
  •  | 
  •  

Question

Je suis un récent diplômé en IA (environ 2 ans) et je travaille pour une opération modeste.Il m'incombe (principalement parce que je suis le premier « adoptant » du département) de créer un document de base (lu utile ?) sur les normes de codage C#.

Je pense que je devrais expliquer que je suis probablement l'ingénieur logiciel le plus jeune, mais j'attends avec impatience cette tâche car j'espère que je pourrai réellement produire quelque chose à moitié utilisable.J'ai effectué une recherche assez approfondie sur Internet et lu des articles sur ce qu'un document sur les 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 quoi que ce soit d'aussi draconien et proscriptif au point d'étouffer le flair personnel, mais d'essayer d'obtenir une méthodologie générale et d'être d'accord. normes (par ex.conventions de dénomination) pour aider à rendre le code des individus plus lisible.

Alors voilà....Aucune suggestion?Du tout ?

Était-ce utile?

La solution

Nous commençons par

puis documentez les différences et les ajouts par rapport à cette référence.

Autres conseils

IDesign dispose d'un document sur les normes de codage C# qui est couramment utilisé.Voir aussi le Lignes directrices pour la conception du cadre 2e édition.

Ironiquement, l’établissement de 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 qu'ils jugent importantes.L’application de tout type de lignes directrices nécessite un certain degré d’adhésion de la part des gens.Si vous leur déposez soudainement un document spécifiant comment écrire du code, vous rencontrerez de la résistance, que vous soyez le plus jeune ou le plus expérimenté.

Une fois que vous avez un ensemble de propositions, envoyez-les à l'équipe pour commentaires et examen.Encore une fois, amenez 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 du code s’y conforme, il sera alors payant d’en formaliser l’utilisation.Adopter une norme contraire causera plus de chagrin que cela 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 face à un dilemme : le code d'un certain module doit-il être conforme à la nouvelle norme ou suivre le style de code existant.

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

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

Le problème avec les documents sur les normes de codage est que personne ne les lit vraiment comme il le devrait, 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 choses peuvent nuire à la programmation, alors soyez prudent.

N'écrivez jamais vos propres normes de codage, utilisez celles de MS (ou celles de Sun ou...selon votre langue).L'indice réside dans le mot standard : le monde serait beaucoup plus facile à coder si chaque organisation n'avait pas décidé d'écrire le sien.Qui pense vraiment qu'apprendre un nouvel ensemble de « normes » à chaque fois que vous changez d'équipe/de projet/de rôle est une bonne utilisation du temps de chacun ?Le mieux que vous devriez faire est de résumer les points critiques, mais je vous déconseille de le faire car ce qui est critique varie d'une personne à l'autre.Deux autres points que j'aimerais souligner sur les normes de codage

  1. La proximité 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 modifiez du code que vous n'avez pas écrit, suivez les « normes de codage locales », c'est-à-dire :faites en sorte que votre nouveau code ressemble au code environnant.

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

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

Norme de codage C#

Attention :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 à des fins de 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.Ainsi, vous pourriez avoir quelque chose comme ceci dans le corps d’une méthode :

m_strName = p_strName;

Horrible.Vraiment horrible.

j'ajouterais Code terminé 2 à la liste (je sais que Jeff est un peu fan ici)...Si vous êtes un développeur junior, le livre s'avère utile pour définir votre esprit de manière à jeter les bases des meilleures pratiques d'écriture de code et de création de logiciels qui existent.

Je dois dire que j'y suis arrivé un peu tard dans ma carrière, mais cela régit une grande partie de ma façon de penser le codage et le développement de frameworks dans ma vie professionnelle.

Ça vaut le détour ;)

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

Je serais tenté d'imposer StyleCop de Microsoft comme standard.Il peut être appliqué au moment de la construction.mais si vous avez du code existant, appliquez simplement l'utilisation de 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 qui IDesign a mis en place.Mais ce n'est pas pour ça que je poste...

Le plus délicat dans mon entreprise était de prendre en compte toutes les différentes langues.Et je sais que mon entreprise n'est pas seule dans ce cas.Nous utilisons C#, C, assembly (nous fabriquons des appareils), SQL, XAML, etc.Même s’il existe certaines similitudes entre les normes, chacune est généralement traitée différemment.

Je crois également que des normes de niveau plus élevé ont un plus grand impact sur la qualité du produit final.Par exemple:comment et quand utiliser les commentaires, lorsque les exceptions sont obligatoires (par ex.événements initiés par l'utilisateur), s'il faut (ou quand) utiliser des exceptions ou non.valeurs de retour, quelle est la manière objective de déterminer ce qui 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 penchant pour 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 ne les approuve et (probablement plus important encore) personne ne les applique, alors tout cela ne sert à rien.

Comme j'ai écrit celui publié pour Philips Medical Systems et celui 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 de normes de codage.J'ai essayé d'écrire le seul CodePlex en gardant à l'esprit les différences d'opinions et j'ai consacré la majeure partie de l'introduction à la manière de gérer cela dans votre organisation particulière.Lisez-le et faites-moi part de vos commentaires.....

Règles SSW

Il comprend quelques standards C# + bien plus encore....principalement destiné aux développeurs Microsoft

Vous êtes très probablement mis en place pour échouer.Bienvenue dans l'industrie.

Je ne suis pas d'accord : tant qu'il crée le document, le pire qui puisse arriver 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'elles préfèrent.De cette façon, vous n'avez plus rien à faire et les autres ont la responsabilité de justifier leurs changements.

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

Une autre source peut être Directives de codage professionnelles C#/VB .NET.

Je suis un grand fan du livre de Francesco Balena "Lignes directrices pratiques et bonnes pratiques pour les développeurs VB et C#".

Il est très détaillé et couvre tous les sujets essentiels. Il ne se contente pas de vous donner la règle, mais explique également la raison de la règle et fournit même une anti-règle dans laquelle il pourrait y avoir deux bonnes 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 en gros : "Utiliser StyleCop".

Je dois suggérer le dotnetspider.com document.
C’est un document formidable et détaillé qui est utile partout.

J'ai déjà utilisé Juval et c'est fini, voire excessif, mais je suis paresseux et maintenant je me conforme simplement à la volonté de Affûteur.

Vous pouvez consulter ceci, les 7 principales normes de codage et documents de référence pour les développeurs C#/.NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html J'espère que cela t'aides

Je pense faire écho aux autres commentaires ici selon lesquels les lignes directrices MS déjà liées sont un excellent point de départ.Je modèle 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'aimait pas trop ça :D

Vous avez une tâche amusante qui vous attend, mon ami.Bonne chance et n'hésitez pas à demander si vous avez besoin de quelque chose de plus :)

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

Mes normes sont basées sur cela avec quelques ajustements et quelques mises à jour pour .NET 2.0 (la norme Philips est écrite pour .NET 1.x et est donc un peu datée).

Dans le code que j'écris, je suis habituellement Directives de conception du .NET Framework pour les API exposées publiquement et Directives de codage mono pour boîtier de membre privé et empreinte.Mono est une implémentation open source de .NET, et je pense que ces gars 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 de Mono, c'est qu'elles utilisent des onglets à 8 espaces.Cependant, après un peu de pratique, j'ai découvert que cela m'aidait à écrire du code moins compliqué en appliquant une sorte de limite d'indentation.

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

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'imposez rien de tel si vos collègues ne l'aiment pas (sauf si vous êtes prêt à contribuer à Mono ;-)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top