Y a-t-il des suggestions pour le développement d’un langage c# normes de codage / meilleures pratiques document ?

Question

Je suis un récent AI supérieures (vers 2 ans) de travail pour une opération modeste. Il est tombé à moi (surtout que je suis le premier "adoptant" dans le département) pour créer une base (lecture utile?) C# normes de codage de document.

Je pense que je dois expliquer que je suis probablement le plus jeune ingénieur logiciel, mais je suis impatient de cette tâche, j'espère que je pourrait en fait être en mesure de produire quelque chose de la moitié utilisable. J'ai fait un assez vaste, la recherche de l'Internet et de lire des articles sur ce que les normes de codage document devrait / ne devrait pas contenir. Cela semble être une bonne place pour demander des suggestions.

Je me rends compte que je suis potentiellement l'ouverture d'une porte à tout un monde de désaccord au sujet de "la meilleure façon de faire les choses". J'ai à la fois comprendre et respecter le fait indéniable que chaque programmeur a préféré la méthode de résolution de chaque tâche individuelle, comme un résultat que je ne suis pas à la recherche d'écrire quelque chose d'aussi draconianly prescriptive comme pour étouffer le personnel de flair, mais pour essayer et obtenir une méthodologie générale et les normes convenues (par exemple, les conventions de nommage) pour aider à rendre les individus de code plus lisible.

Donc, ici, va .... toutes les suggestions? Tout?

Answer 1

Nous commençons par

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

et puis documenter les différences et ajouts à cette base.

Answer 2

IDesign a un langage c# codage de document de normes qui est couramment utilisé. Voir aussi le Framework Design Guidelines 2e éd.

Answer 3

Ironiquement définissant les standards actuels sont probablement la partie la plus facile.

Ma première suggestion serait d'obtenir des suggestions à partir d'autres ingénieurs sur ce qu'ils devraient être couverts, et ce que les lignes directrices qu'ils jugent importants. L'application de tout type de lignes directrices exige un degré d'adhésion de la part des gens. Si vous avez soudainement déposer un document qui spécifie comment écrire du code que vous rencontrez de la résistance, que vous êtes le plus junior ou senior gars.

Après vous avez un ensemble de propositions puis les envoyer à l'équipe de rétroaction et d'examen. Encore une fois, amener les gens à tous d'acheter.

Il y a peut-être déjà informel des pratiques de codage qui sont adoptées (e.g préfixer les variables de membre, camelcase noms de fonction). Si cela existe, et la plupart du code est conforme à elle, alors elle va payer pour officialiser son utilisation. L'adoption d'un contraire standard va causer plus de chagrin que ça vaut le coup, même si c'est quelque chose de généralement recommandé.

Il est également intéressant de considérer la refactorisation de code existant pour répondre à la nouvelle codification des normes. Cela peut sembler une perte de temps, mais ayant le code qui ne respecte pas les normes peuvent être contre-productifs, car vous aurez un méli-mélo de styles différents. Il laisse aussi dans un dilemme si le code dans un module doit être conforme à la nouvelle norme ou de suivre le code existant de style.

Answer 4

J'ai toujours utilisé Juval Lowy du pdf comme référence lors de codage des normes et des meilleures pratiques à l'interne. Il suit de très près de FxCop/Source d'Analyse, qui est un autre outil précieux pour s'assurer que la norme est respectée. Entre ces outils et références, vous devriez être en mesure de venir avec une norme agréable que tous vos les développeurs n'ont pas l'esprit de suite et d'être en mesure de les appliquer.

Answer 5

Les autres affiches ont souligné vous à la ligne de base, tout ce que je voudrais ajouter est de faire de votre document court, doux et au point, en employant une forte dose de Strunk et Blanc de distinguer les "must-have" de la "ce serait bien si...".

Le problème avec les normes de codage de documents, c'est que personne ne lit vraiment comme ils le devraient, et quand ils lisent, ils ne les suivent pas. La probabilité d'un tel document en cours de lecture et de suivi varie de façon inversement proportionnelle à sa longueur.

Je suis d'accord FxCop est un bon outil, mais aussi une grande partie de cela peut prendre du plaisir dès la sortie de la programmation, donc soyez prudent.