Convention de dénomination des variables en langage de programmation C # [fermé]

Je regarde une vidéo sur C # sur les variables. L'auteur déclare une variable à l'intérieur d'une méthode et l'a nommée ainsi: string MyName = "James";

ma question est: quelle convention est recommandée par .Net Framework. S'agit-il d'un boîtier Pascal comme dans l'exemple ci-dessus ou d'un boîtier camel?

c# coding-standards variables conventions

— Kaser
source

Le problème avec cette question, que vous ne connaissiez pas donc ce n'est pas de votre faute, c'est qu'il n'y a en fait aucune convention canonique pour C #. Il existe des conventions communes; malheureusement plus d'un, mais il serait assez difficile pour vous d'obtenir ici une réponse qui est tout sauf une pure opinion. Désolé de voter pour fermer; ma suggestion: passer du temps à lire le code dans les référentiels github et codeplex populaires pour voir quelles conventions ils utilisent en tant que personnes qui écrivent la plupart des plus populaires sont des gens expérimentés dans l'industrie et aussi canoniques que ce que vous trouverez.

— Jimmy Hoffa

Conventions de dénomination de MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

— Yusubov

@Yusubov Celles-ci décrivent la dénomination des parties publiques des bibliothèques, pas les variables locales.

— svick

Réponses:

Je ne pense pas qu'il y ait quelque chose comme une convention «officielle». Pour autant que je sache, ce qui suit est considéré comme une bonne pratique par de nombreux développeurs C # expérimentés:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

Avec cette approche, on peut distinguer entre les variables locales ainsi que les membres publics et privés par le cas de leur première lettre.

Comme pour toute convention de codage, cela est également soumis à des préférences personnelles. Par conséquent, il n'y a pas de réponse définitive. Un objectif général devrait être de garder le code aussi lisible et compréhensible que possible.

— glaed
source

+1 C'est proche du style que j'ai vu. Je crois que c'est généralement tiré du style utilisé dans les exemples de MSDN. Habituellement, je vois des propriétés obtenir PascalCase, les sections locales obtenir camelCaseet les membres privés obtenir un _leadingUnderscore.

— KChaloux

Voulez-vous dire des champs ou des propriétés lorsque vous avez dit des variables membres?

— Kaser

Les développeurs Delphi ont tendance à paramètres fonction nom / méthode en les préfixant avec un « a »: (aParameter: string). Je me rends compte que les paramètres sont essentiellement des variables locales, en particulier lorsqu'ils sont transmis par valeur, mais il est souvent très utile de "voir" qu'un var est réellement passé en tant que paramètre. Existe-t-il une telle convention en C #?

— Marjan Venema

Et un autre: les champs membres. Delphians les préfixe avec un «F». Je l' ai vu le code C # qui les déclare avec un trait de soulignement: private string _SomeString. Diriez-vous que c'est une convention? (Je plonge juste mes orteils en C # et je m'interroge sur ce genre de choses).

— Marjan Venema

C'est inexact. Il existe des conventions de dénomination publiées pour les membres publics (et les classes publiques, etc.).

— svick

Les conventions de dénomination du .Net Framework ( v4.5 , v1.1 ) sont agnostiques à ce sujet. Ils ne spécifient pas de norme pour nommer les variables locales. Vous devrez décider de votre propre convention pour les nommer.

J'utilise personnellement camelCase et désambiguïser les variables membres des noms de paramètres avec thissi nécessaire. Mais les soulignés (ie _memberVariable) sont également valides.

— Robert Harvey
source

C'est exactement la raison de l'utilisation des conventions de dénomination - en utilisant thispour distinguer les variables locales des champs / propriétés. 5 lettres supplémentaires à chaque fois, c'est trop à mon humble avis.

— Sinatr