Quel type de préfixe utilisez-vous pour les variables membres?

https://stackoverflow.com/questions/111605

02-07-2019
|

Question

Sans aucun doute, il est essentiel pour la compréhension du code de donner un préfixe aux variables membres afin de les distinguer facilement de " normal " variables.

Mais quel genre de préfixe utilisez-vous?

Je travaille sur des projets pour lesquels nous avons utilisé m _ comme préfixe. Sur d'autres projets, nous avons uniquement utilisé un trait de soulignement (ce que je n'aime pas personnellement, car un soulignement n'est pas assez démonstratif).

Sur un autre projet, nous avons utilisé une forme de préfixe long, incluant également le type de variable. mul _ , par exemple, est le préfixe d'une m variable de membre de type u nsigned l ong.

Faites-moi savoir quel type de préfixe vous utilisez (et donnez-nous une raison de le choisir).

EDIT: la plupart d'entre vous semblent coder sans préfixes spéciaux pour les variables membres! Cela dépend-il de la langue? D'après mon expérience, le code C ++ utilise généralement un trait de soulignement ou m _ comme préfixe des variables membres. Qu'en est-il des autres langues?

La solution

Sans aucun doute, il est essentiel pour la compréhension du code de donner un préfixe aux variables membres afin de les distinguer facilement de " normal " variables.

Je conteste cette affirmation. Ce n'est pas le moins du monde nécessaire si vous avez une coloration syntaxique à moitié décente. Un bon IDE peut vous permettre d’écrire votre code en anglais lisible, et peut vous montrer le type et la portée d’un symbole de différentes manières. Eclipse fait du bon travail en soulignant les déclarations et les utilisations d’un symbole lorsque le point d’insertion se trouve sur l’un d’eux.

Modifier, merci, un bon surligneur de syntaxe comme Eclipse vous permettra également d’utiliser du texte en gras ou en italique, ou de changer complètement les polices. Par exemple, j'aime l'italique pour les choses statiques.

Autre édition: Pensez-y de cette façon. le type et la portée d'une variable sont des informations secondaires. Il devrait être disponible et facile à trouver, mais ne vous a pas crié dessus. Si vous utilisez des préfixes tels que m _ ou des types tels que LPCSTR , cela devient du bruit lorsque vous souhaitez uniquement lire les informations primaires & # 8211; l'intention du code.

Troisième édition: cela s’applique quelle que soit la langue.

Autres conseils

Je n'utilise aucun préfixe du tout. Si je risque de mêler des variables locales ou des paramètres de méthode à des membres de classe, , la méthode ou la classe est trop longue et profite de la scission .

Cela (sans doute) rend non seulement le code plus lisible et plus "fluide", mais surtout encourage les classes et les méthodes bien structurées . Au final, le problème est donc complètement différent de celui du préfixe ou du préfixe sans préfixe.

UPDATE: Eh bien, les goûts et les préférences changent, n'est-ce pas? J'utilise maintenant le trait de soulignement comme préfixe des variables membres, car il s'est avéré bénéfique pour la reconnaissance des variables locales et des membres à long terme. Les nouveaux membres de l’équipe, en particulier, ont parfois du mal à distinguer les deux.

Aucun. J'avais l'habitude d'utiliser le trait de soulignement, mais j'en ai parlé sur un projet où les autres ne l'aimaient pas et ne l'avaient pas manqué. Un IDE décent ou une mémoire décente vous dira ce qu’est une variable membre et ce qui ne l’est pas. L'un des développeurs de notre projet insiste pour mettre "ceci". devant chaque variable membre, et nous l’amusons quand nous travaillons sur des zones de code qui sont nominalement "son".

Souligner uniquement.

Dans mon cas, je l'utilise parce que c'est ce que dit le document sur les normes de codage sur mon lieu de travail. Cependant, je ne vois pas l'intérêt d'ajouter m_ ou quelque chose d'horrible en hongrois au début de la variable. Le caractère de soulignement minimaliste reste lisible.

Il est plus important d'être cohérent que tout, alors choisissez quelque chose sur lequel vous et vos coéquipiers pouvez être d'accord et respectez-le. Et si le langage que vous codez a une convention, vous devriez essayer de vous y tenir. Rien de plus déroutant qu’une base de code qui suit une règle de préfixage de manière incohérente.

Pour c ++, il y a une autre raison de préférer m_ à _ en plus du fait que _ préfixe parfois les mots-clés du compilateur. Le m représente la variable membre. Cela vous donne également la possibilité de ne pas faire l’ambiguïté entre les locales et les autres classes de variables, s_ pour static et g_ pour global (mais bien sûr, n’utilisez pas de globales).

En ce qui concerne les commentaires que l'EDI prendra toujours en charge, l'IDE est-il vraiment la seule façon dont vous regardez votre code? Votre outil de différenciation a-t-il le même niveau de qualité pour la hiérarchie syntaxique que votre IDE? Qu'en est-il de votre outil d'historique de révision du contrôle de code source? Ne vous jamais même cat un fichier source à la ligne de commande? Les IDE modernes sont d'excellents outils d'efficacité, mais le code doit être facile à lire quel que soit le contexte dans lequel vous le lisez.

Je préfère utiliser ce mot clé. Cela signifie que this.data ou this- > data au lieu d'une dénomination dépendante de la communauté.



 Parce que: 


 avec les IDE saisissant  this.  popups intellinsense 
 sa évidente pour tout le monde sans savoir nommer défini 


 BTW préfixe les variables avec des lettres pour indiquer que leur type est obsolète avec de bons IDE et me rappelle ce  L'article de Joel



	
		
	
	
			 Nous utilisons m_, puis une notation Simonyi légèrement modifiée, comme l’a dit Rob dans une réponse précédente. Donc, préfixer semble utile et m_ n'est pas trop intrusif et facile à rechercher. 

 Pourquoi la notation du tout? Et pourquoi ne pas simplement suivre (pour .NET) les recommandations de la notation Microsoft qui reposent sur la casse des noms? 

 Dernière question: comme indiqué, VB.NET est indifférent au boîtier. Il en va de même pour les bases de données et (en particulier) les administrateurs de base de données. Lorsque je dois garder les références client et client (en C #, par exemple), mon cerveau est blessé. Ainsi, la casse est une forme de notation, mais pas très efficace. 

 La notation de préfixe a une valeur de plusieurs manières: 


 Augmente la compréhension humaine du code sans utiliser l'EDI. Comme dans la révision du code - que je trouve toujours plus facile au début sur papier. 
 Avez-vous déjà écrit T-SQL ou un autre processus stocké dans le SGBDR? Utiliser la notation préfixe sur les noms de colonne de base de données est vraiment utile, en particulier pour ceux qui aiment utiliser des éditeurs de texte pour ce genre de choses. 


 En résumé, il peut être utile de préfixer une forme de notation car il existe encore des environnements de développement où les IDE intelligents ne sont pas disponibles. Pensez à l'IDE (un outil logiciel) comme nous permettant quelques raccourcis (comme le typage intellisense), mais ne comprenant pas l'environnement de développement complet. 

 Un environnement de développement intégré est un environnement de développement intégré, de la même manière qu’une voiture est un réseau de transport: n’est qu’un élément d’un système plus vaste. Je ne veux pas suivre une "voiture". convention comme rester sur des routes balisées, quand parfois, il est plus rapide de traverser un terrain vacant. S'en remettre à l'IDE pour suivre le typage variable serait comme avoir besoin du GPS de la voiture pour parcourir le terrain vacant. Mieux vaut avoir les connaissances (même si cela peut être gênant d'avoir "m_intCustomerID") sous une forme portable plutôt que de retourner à la voiture pour chaque petit changement de parcours. 

 Cela dit, la convention m_ ou le "this" convention sont lisibles. Nous aimons m_ car il est facile à rechercher et permet toujours au type de saisie de le suivre. Convenu que trop d’activités de code de structure utilisent un trait de soulignement simple. 
	


	
		
	
	
			 En utilisant C #, je suis passé du préfixe "m _" à  juste un trait de soulignement , car "m_" est  un héritage du C ++ . 

 Les directives officielles de Microsoft vous interdisent d'utiliser des préfixes et  d'utiliser la casse-chameau sur les membres privés  et la  cascal-casse sur les membres publics . Le problème est que cela entre en conflit avec une autre directive de la même source, qui stipule que  vous devez rendre tout le code compatible avec toutes les langues utilisées dans .NET . Par exemple, VB.NET ne fait pas la différence entre les boîtiers. 

 Donc, juste un trait de soulignement pour moi. Cela facilite également l'accès via IntelliSense, et les membres publics qui appellent uniquement du code externe n'ont pas à voir les traits de soulignement visuellement désordonnés. 

 Mise à jour: je ne pense pas que le  C # "this." préfixe  aide le "moi". dans VB, qui verra toujours " Me.age " identique à "Me.Age". 
	


	
		
	
	
			 Cela dépend du framework que j'utilise! Si j'écris du code MFC, j'utilise la  m _  et la notation hongroise. Pour les autres éléments (qui ont tendance à être STL / Boost), j’ajoute un suffixe de soulignement à toutes les variables membres et je ne me soucie pas de la notation hongroise. 

  Classe MFC  

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};


  Classe STL  

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};


 Maintenant, cela peut sembler un peu étrange - deux styles différents - mais cela fonctionne pour moi, et écrire beaucoup de code MFC qui n'utilise pas le même style que MFC lui-même est vraiment moche. 
	


	
		
	
	
			 Je préfixe les variables membres avec "m" et les paramètres (dans la fonction) avec "p". Le code ressemblera donc à: 

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}


 Je trouve que cela vous indique rapidement la portée de base de toute variable - si aucun préfixe n'est défini, c'est un local. De plus, lors de la lecture d’une fonction, vous n'avez pas besoin de penser à ce qui est transmis et à ce qui est juste une variable locale. 
	


	
		
	
	
			 Cela dépend vraiment de la langue.
Je suis un gars de C ++ et préfixer le tout par un trait de soulignement est un peu délicat. La langue réserve des éléments commençant par un trait de soulignement pour la mise en œuvre dans certains cas (en fonction de l'étendue). Il existe également un traitement spécial pour le double soulignement, ou le soulignement suivi d'une lettre majuscule. Donc, je dis simplement d'éviter ce désordre et choisissez simplement un autre préfixe. 'm' est ok IMO. 'm_' c'est un peu cher, mais pas terrible non plus. Une question de goût vraiment. 

 Mais méfiez-vous des _leadingUnderscores. Vous serez surpris du nombre de composants internes du compilateur et de la bibliothèque ainsi nommés, et il y a certainement de la place pour des accidents et des mélanges si vous ne faites pas très attention. Il suffit de dire non. 
	


	
		
	
	
			 La plupart du temps, j'utilise python. Python nécessite que vous utilisiez self.foo afin d'accéder à l'attribut foo de l'instance de la classe en cours. De cette manière, le problème de confusion des variables locales, des paramètres et des attributs de l'instance sur laquelle vous travaillez est résolu. 

Généralement, j'aime cette approche, même si je n'aime pas être forcé de le faire. Ainsi, mon moyen idéal de le faire est de ne pas le faire et d’utiliser une forme d’accès aux attributs sur this ou self afin de récupérer les variables membres. De cette façon, je n'ai pas à encombrer les noms de méta-données. 
	


	
		
	
	
			 Si la langue prend en charge le  mot clé  this  ou  Moi , n'utilisez pas de préfixe, mais utilisez plutôt ce mot clé. 
	



	
		
	
	
			 une autre astuce est la  convention de dénomination : 

 Toutes les variables membres sont nommées comme d'habitude, sans préfixe (ou "this.", c'est habituel dans le projet) 

 Mais elles seront facilement différenciées des variables locales car dans mon projet, ces variables locales sont toujours nommées: 


  a  quelque chose: représente un objet. 
  certains  ManyThings: liste d'objets. 
  est  ASate ou  a  quelque chose: pour l'état booléen. 


 Toute variable qui ne commence pas par 'a', 'une' ou 'est / a' est une variable membre. 
	


	
		
	
	
			 Etant donné que VB.NET n’est pas sensible à la casse, je préfixe mes variables membres avec un trait de soulignement et une casse de chameau le reste du nom. Je capitalise les noms de propriété. 

Dim _valueName As Integer

Public Property ValueName() As Integer
	


	
		
	
	
			 Je suis avec les gens qui n'utilisent pas de préfixes. 

 Les IDE sont si efficaces de nos jours qu'il est facile de trouver les informations sur une variable d'un coup d'œil, depuis la coloration syntaxique, les info-bulles survolées et la navigation facile vers sa définition. 

 Cela s'ajoute à ce que vous pouvez obtenir du contexte de la variable et des conventions de dénomination (telles que lowerCamelCase pour les variables locales et les champs privés, UpperCamelCase pour les propriétés et les méthodes, etc.) et des options telles que "has hasXXXX". et "isXX" pour les booléens. 

 Je n'ai pas utilisé de préfixes depuis des années, mais j’étais un "ceci". préfixe monstre mais je suis parti que si absolument nécessaire (merci, Resharper). 
	


	
		
	
	
			 Je suis bizarre et je préfixe les variables membres avec les initiales du nom de la classe (qui est camel). 

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;


 La plupart des gens de Delphi n'utilisent que F. 

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;
	


	
		
	
	
			 Un seul  _  à titre d'indicateur visuel. (C #) 


 aide à regrouper les membres avec intellisense. 
 Il est plus facile de repérer les variables membres lors de la lecture du code. 
 difficile de masquer une variable membre avec une définition locale. 
	


	
		
	
	
			  _  au lieu de  this.  

 J'utilise aussi  _  au lieu de  this.  car il est  plus court  ( 4  moins) et c'est un bon indicateur des variables de membre. En outre, en utilisant ce préfixe, vous éviterez les conflits de noms. Exemple: 

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}


 Comparez-le avec ceci: 

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}


 Je trouve le premier exemple plus court et plus clair. 
	


	
		
	
	
			 Cela dépend un peu de la langue dans laquelle vous travaillez. 

 En C #, vous pouvez référencer n’importe quel membre en utilisant le préfixe 'this', par exemple. 'this.val', ce qui signifie qu'aucun préfixe n'est requis. VB a une capacité similaire avec "Moi". 

 Dans les langues où il existe une notation intégrée pour indiquer l'accès des membres, je ne vois pas l'intérêt d'utiliser un préfixe. Dans d’autres langues, j’imagine qu’il est logique d’utiliser toute convention communément admise pour cette langue. 

 Notez que l'un des avantages de l'utilisation de la notation intégrée est que vous pouvez également l'utiliser pour accéder aux propriétés et méthodes de la classe sans compromettre vos conventions de dénomination (ce qui est particulièrement important lorsque vous accédez à des membres non privés). . La principale raison d'utiliser n'importe quel type d'indicateur est le fait que vous indiquez qu'il est possible que des effets secondaires se produisent dans la classe. Il est donc judicieux de l'indiquer lorsque vous utilisez d'autres membres, qu'ils soient un champ / une propriété / une méthode / etc. . 
	


	
		
	
	
			 J'utilise un étui et un soulignement comme beaucoup ici. J'utilise le trait de soulignement parce que je travaille avec C # et que je me suis habitué à éviter le mot clé "this" dans mes constructeurs. Comme je propose des variantes de la méthode des boîtiers de chameaux, le trait de soulignement me rappelle le champ d'application avec lequel je travaille à l'époque. Sinon, je ne pense pas que cela soit important tant que vous n'essayez pas d'ajouter des informations inutiles qui sont déjà évidentes dans le code. 
	


	
		
	
	
			 J'avais l'habitude d'utiliser le préfixe m_ en C ++ mais en C #, je préfère simplement utiliser la casse camel pour le champ et la casse pascal pour sa propriété. 
private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}
	


	
		
	
	
			 J'aime m_, mais tant que la convention est utilisée dans la base de code, je suis cool avec. 
	


	
		
	
	
			 Votre exemple mul_ se dirige vers la notation hongroise "Apps" de Charles Simonyi. 

 Je préfère garder les choses simples et c'est pourquoi j'aime utiliser m_ comme préfixe. 

 Faites cela beaucoup plus facilement pour voir où vous devez aller pour voir la déclaration originale. 
	


	
		
	
	
			 J'ai tendance à utiliser m_ en C ++, mais cela ne me dérange pas de le laisser en Java ou en C #. Et cela dépend de la norme de codage. Pour les codes existants qui combinent soulignement et m_, je refactoriserais le code selon un standard (avec une taille de code raisonnable) 
	


	
		
	
	
			 J'utilise @. 

: D j / k - mais si cela dépend en quelque sorte de la langue. S'il y a des accesseurs / setters, je mettrai généralement un _ devant la variable private membre et le getter / setter aura le même nom sans le _. Sinon, d'habitude, je n'en utilise pas. 
	


	
		
	
	
			 Pour mes propres projets, j’utilise _ comme postfixe (comme l’a souligné Martin York, _ comme préfixe est réservé par la norme C / C ++ pour les implémentations du compilateur) et i lorsque je travaille sur  Projets Symbian . 
	


	
		
	
	
			 En Java, une convention courante consiste à préfacer les variables de membre avec "my". etUtilisezCamelCaseForTheRestOfTheVariable. 
	


	
		
	
	
			 Aucune si ce n'est pas nécessaire, soulignez simplement autrement. S'applique au python. 
	


	
		
	
	
			 S'il est vraiment nécessaire de préfixer les variables membres, je préférerais certainement  m _  à seulement un trait de soulignement. Je trouve qu'un trait de soulignement en soi réduit la lisibilité et peut être confondu avec les mots réservés C ++. 

 Cependant, je doute que les variables membres nécessitent une notation spéciale. Même en ignorant l'aide de l'EDI, il n'est pas évident de comprendre pourquoi il y aurait confusion entre ce qui est une variable locale et ce qui est une variable membre.



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