Pourquoi la plupart des champs (membres de la classe) du didacticiel Android commencent-ils par `m`?


446

Je connais les règles de l'affaire des chameaux, mais je suis confus avec cette règle m. Qu'est ce que cela signifie? Je suis développeur PHP. «Nous» utilisons les premières lettres des variables comme indication de type, comme «b» pour booléen, «i» pour entier et ainsi de suite.

Est-ce que je suis une chose Java? Cela signifie-t-il pour mobile? mixte?


281
ce préfixe ne fait que gâcher la lisibilité ...
Dapeng

10
indiquant que le type en tant que préfixe est mauvais et appelé notation hongroise voir thc.org/root/phun/unmaintain.html et kernel.org/doc/Documentation/CodingStyle
Muayyad Alsadi

10
parce qu'ils n'avaient pas beaucoup de connaissances sur le style de code java pour commencer
Victor Ionescu

10
À mon avis, si vous avez du mal à différencier les variables locales des variables membres, vous avez des problèmes beaucoup plus importants que de vous conformer à une convention de code. Voici la convention que j'utilise (parfois): Long Life, Long Name. Vie courte, nom court. N'ont pas été confondus jusqu'à présent.
Brandon

17
Un vrai préfixe stupide. Utilisez votre IDE pour générer des setters / getters et vous vous retrouvez avec getmName () et setmName ()! Des outils comme Lombok pour les générateurs, les getters, les constructeurs, etc. généreront le préfixe m. Dans mon option, le préfixe m n'ajoute pas de valeur et doit être supprimé de la convention de dénomination.
userM1433372

Réponses:


551

Cette notation provient des directives de style de code AOSP (Android Open Source Project) pour les contributeurs :

Suivez les conventions de dénomination des champs

  • Les noms de champs non publics et non statiques commencent par m.
  • Les noms de champs statiques commencent par s.
  • Les autres champs commencent par une lettre minuscule.
  • Les champs finaux statiques publics (constantes) sont ALL_CAPS_WITH_UNDERSCORES.

Notez que le guide de style lié est pour le code à contribuer au projet Android Open Source.

Ce n'est pas un guide de style pour le code des applications Android individuelles.


33
Intéressant .. le style de code Java de Google contredit en fait le style de code AOSP à ce sujet.
Gautam

51
Je pense qu'en ces temps c'est absurde, surtout de le faire dans votre application! "Vos classes et fonctions doivent être suffisamment petites pour que vous n'en ayez pas besoin. Et vous devez utiliser un environnement d'édition qui met en surbrillance ou colorise les membres pour les distinguer. En outre, les gens apprennent rapidement à ignorer le préfixe (ou suffixe) pour voir la partie significative du nom. Plus nous lisons le code, moins nous voyons les préfixes. Finalement, les préfixes deviennent un encombrement invisible et un marqueur de code plus ancien. " - Robert Martin dans Clean Code
mikugo

4
Contredit le Guide de style Java de Google - "Les noms de champs non constants (statiques ou non) sont écrits dans lowerCamelCase. ... Par exemple, computedValues..."
AlikElzin-kilaka

Pour les applications individuelles, je me souviens d'un bon conseil suggérant d'utiliser des initiales en minuscules du nom de l'application au lieu de «m».
abcoep

4
Veuillez ajouter votre commentaire à cette pétition pour supprimer la règle code.google.com/p/android/issues/detail?id=226814
likejudo

83

De nombreuses lignes directrices de codage utilisent m pour les «membres» d'une classe. Ainsi, lorsque vous programmez, vous pouvez voir la différence entre les variables locales et les variables membres.


90
Tous les IDE modernes différencient les sections locales et les membres par couleur / police, ce qui est beaucoup plus lisible à mmon humble avis que le préfixe.
Dzmitry Lazerka

5
D'accord. Je trouve la chose m très ennuyeuse, mais uniquement parce qu'IntelliJ est génial.
ZakTaccardi

Veuillez ajouter votre commentaire à cette pétition pour supprimer la règle code.google.com/p/android/issues/detail?id=226814
likejudo

4
@DzmitryLazerka dans la plupart des outils de révision de code vous n'avez pas ce niveau de surbrillance. Cela fait donc sens dans un grand projet open source.
JWqvist

@DzmitryLazerka qu'en est-il de la lecture de code dans le bloc-notes ou github et ainsi de suite?
user924

57

Qu'est-ce que le mpréfixe?

msignifie membre variable ou membre de données. Utilisez le mpréfixe pour les champs non publics et non statiques.

Quand utiliser?

private String mCityName;
private float mTemperature;

Quand ne pas utiliser?

public static int mFirstNumber;
public static final String mDATABASE_NAME;

Ce que je fais?

Personnellement, je ne l'utilise pas. Cela rend le code plus compliqué et rend la lisibilité chaotique. Si vous utilisez toujours le Bloc-notes pour le codage, je n'ai pas de mots, mais les IDE modernes sont capables de mettre en surbrillance et de colorier les variables membres et locales ou toute autre chose.

Conclusion

Utilisation? "Oui" ou "Non" est votre choix personnel.


1
vous pouvez également l' utiliser pour public static int, mais utiliser au slieu de m: public static int sFirstNumber;, voir stackoverflow.com/a/49453184/7767664
user924

31

S'il s'agit de variables membres dans les classes, le «m» signifie «membre». De nombreux programmeurs Java le font, bien qu'avec les IDE modernes, cela ne soit pas nécessaire car vous avez la mise en surbrillance, la souris sur les info-bulles, etc.


9
Je dirais que même avec un IDE moderne, il est agréable de préfixer les membres avec m ou m_ dans le but de faire apparaître toutes les variables membres d'une classe au même endroit lors de l'utilisation de l'achèvement de code. Cela signifie que lorsque vous travaillez dans une classe, vous pouvez simplement appuyer sur m_ + ctrl espace pour obtenir une liste de tous les membres.
Nailer

38
Cloueur, vous pourriez obtenir le même résultat en utilisant ceci. + espace ctrl :)
Romain Guy

3
De plus, si vous imprimez la liste des codes, cela est utile - vous n'avez pas les info-bulles pour vous aider là-bas (oui, j'aime imprimer le code et le lire dans un fauteuil ou même au lit parfois).
B. Clay Shannon,

3
@domenicop Je ne suis pas pro m- préfixe, mais je suppose que l'idée est de distinguer les types d'attributs au sein d'une classe. Cela étant dit, je n'utilise généralement aucun attribut public non statique, sauf dans les classes qui contiennent exclusivement ces attributs et aucune logique métier (classes d'enregistrements). Dans ce cas, le m est inutile car il n'y a pas de logique métier dans la classe. Par conséquent, il est préférable de le supprimer pour plus de lisibilité en dehors de la classe (lorsque vous référencez ces champs).
Joffrey

2
À mon avis, si vous ne pouvez pas facilement distinguer les champs, les paramètres et les variables sans utiliser de tels préfixes, cela signifie qu'il y a un problème avec le code. La classe ou la méthode est probablement trop grande.
Konrad Morawski

9

Selon le livre Clean Code, ce n'est pas un code propre.

Vous n'avez pas besoin de préfixer les variables membres avec m . De plus, les gens apprennent rapidement à ignorer le préfixe ou le suffixe pour voir la partie significative du nom.


9

Si vous avez des problèmes comme

votre IDE pour générer des setters / getters et vous vous retrouvez avec getmName () et setmName ()

N'oubliez pas de faire ensuite ( Paramètres / Editeur / Style de code / Java / Génération de code ):

entrez la description de l'image ici

Mise à jour: nous n'utilisons pas quelque chose comme ça dans Kotlin (il vaut donc mieux y basculer et ne plus utiliser de préfixes)


6

Je pense que c'est très individuel quelles conventions de code sont utilisées. Je préfère nommer mes variables avec les préfixes suivants:

  • m - Variables de méthode
  • c - Variables de classe
  • p - Variables de paramètres

Mais je suppose que chaque programmeur a son propre style.


7
Étant donné que la plupart des développeurs Java utilisent des IDE qui permettent de définir différents styles visuels pour les variables de classe, de méthode, statiques et de paramètres, je trouve beaucoup plus utile d'avoir par exemple des variables / méthodes statiques soulignées, des variables de classe en italique, etc. Et bien sûr vous pouvez définir vos propres polices et couleurs. Et cela fonctionnera toujours quels que soient les préfixes que vous utilisez. Mais, bien sûr, la magie a disparu lorsque vous quittez l'IDE.
ccpizza

4

Pour prouver que vous ne devez absolument pas traiter cette convention pour nommer les variables dans votre code, je passe une capture d'écran d'un parent Android Studio ci-dessous.

Trouvez que les variables à l'intérieur d'un objet sont spécialement triées pour placer les m-variables plus bas que vos variables natives . Donc, en les nommant dans votre code avec le préfixe "m", vous les cachez dans un tas de vous-même .

entrez la description de l'image ici


3

Le seul avantage que j'ai trouvé de ce style de code, c'est que lors d'une saisie semi-automatique d'une référence à une variable, je sais que je peux taper "m" pour voir uniquement les variables membres.


2

Comme cela a été mentionné précédemment, il est conçu pour différentes variables. Mais il est également très utile pour la génération de code. Si vous appuyez sur "Alt + Insert", vous obtiendrez des fenêtres pour les propriétés de génération de code les plus courantes. Si vous souhaitez générer la méthode "get" pour votre variable, vous obtiendrez.

public class Foo{
   private int bar;

   public int getBar(){
       return this.bar;
   }

   public void setBar(int bar){
       this.bar = bar; 
   }

}

Mais si vous déclarez "m, s", vous obtiendrez:

public class Foo{
private int mBar;

public int getBar(){
   return mBar;
}

public void setBar(int bar){
   mBar = bar;
}
}

Il sera automatiquement généré et "m" ou "s" sera supprimé de votre constructeur, obtenez, définissez le nom des méthodes. Après cela, «get» et «set» pour le champ seront générés sans «m». Andoroid Fle-> Setting-> Code Style-> Java-> Code Genenretion. Et faites comme sur une photo. Peut-être que cela vous aidera. Désolé pour mon eng. Configurer Android


2

Il semble que certains des premiers ingénieurs d'Android / Google aient préféré personnellement commencer les variables membres par «m» et ils l'ont donc recommandé.

Maintenant, cette règle est forcée de tomber dans la gorge des développeurs d'entreprises qui ne sont ni des contributeurs AOSP, simplement parce que cette page est considérée comme des règles de style de code Android. Il y a peu ou pas d'avantages dans cette règle. Google devrait envisager de le supprimer. Sinon, veuillez spécifier que pour les applications Android, lesquelles des règles de style de code sont facultatives.

Veuillez ajouter votre commentaire de soutien à cette pétition pour supprimer la règle https://code.google.com/p/android/issues/detail?id=226814


2

Par souci de lisibilité, la convention des mvariables membres et sdes champs statiques ne devrait plus être utilisée si vous utilisez un IDE moderne comme Android Studio. Android Studio peut faire la différence entre ceux-ci sans ajouter mou s.


1

On peut également dire qu'il représente "le mien", comme dans la classe / instance dit "Cette variable est la mienne et personne d'autre ne peut y accéder." Différent de statique qui, bien qu'il ne soit disponible que pour la classe, il est partagé par toutes les instances de cette classe. Comme si vous dessiniez des cercles, vous devez savoir la taille du rayon de chaque cercle

    private double mRadius;

mais en même temps, vous voulez qu'un compteur garde la trace de tous les cercles, à l'intérieur de la classe de cercle que vous pourriez avoir

    private static int sCircleCount;

puis il suffit d'avoir des membres statiques pour augmenter et diminuer le nombre de cercles que vous avez actuellement.


1

Voici les conventions de dénomination,

  • Les noms de champs non publics et non statiques commencent par m.
  • Les noms de champs statiques commencent par s.
  • Les autres champs commencent par une lettre minuscule.
  • Les champs finaux statiques publics (constantes) sont ALL_CAPS_WITH_UNDERSCORES.

Exemple:

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.