quelque chose que je me suis toujours demandé; Dans une classe où vous pouvez faire référence à un membre en utilisant 'ceci. [Nom]' ou simplement [nom], lequel est préféré?
Par exemple en Java: P>
for (foo f : listOfFoos){
f.incrementBars();
}
7 Réponses :
Utilisez Ceci code> dans Le cas de ombrage variable code> . class MyClass{
int i;//1
public void myMethod(){
i = 10;//referring to 1
}
public void myMethod(int i){//2
i = 10;//referring to 2
this.i = 10 //refering to 1
}
}
Ce code> rendra le code plus lisible en raison de notre état d'esprit anglais p> p>
Personnellement, je trouve ceci. toujours plus lisible. IMO introduit la cohérence. Vous pouvez être sûr que cette variable, quel que soit le contexte, est membre de l'objet.
@Felix Oui, il simulera ce de l'anglais pour que cela faciliterait plus
Je ne pense pas que @felix signifiait que cela ait fait un sens plus sémantique, mais plutôt que la variable se démarque visuellement et réduit la charge cognitive: pendant que vous avez plus de texte à lire, il vous donne des informations directes sur la variable. Je suis moi-même un peu déchiré entre utiliser et ne pas utiliser "cela" systématiquement: chaque fois que je suis dans une IDE ou un éditeur avec un support de langue décent, il apparaît clairement sur dynamique. Mais chaque fois que vous revenez au code de lecture dans du texte en noir sur blanc, cela aide énormément. C'est juste une habitude.
Vous utilisez Il vous permet d'écrire un seigter comme P> ceci code> pour vous assurer et communiquer que vous traitez avec un champ em>. public void setX(int x) {
this.x = x;
}
La seule fois où vous avez besoin ceci. est lorsque la portée actuelle a également une variable du même nom. Je préfère utiliser la convention de _variable pour toutes les variables de classe. De cette façon, je n'ai jamais à utiliser ceci. et ne touchez jamais accidentellement une variable de classe en pensant qu'il s'agissait d'une variable scopée localement.
Il n'y a pas d'ambiguïté. S'il y en avait, vous avez utiliser Certaines personnes recommandent Personnellement, j'évite ceci .
ce pour plus de clarté. D'autres recommandent-ils lorsqu'il n'est pas nécessaire, car il introduit "bruit". Certains IDes et éditeurs modernes peuvent être en mesure d'utiliser la syntaxe en surbrillance sur la couleur (par exemple) des arguments différemment des champs de clarté.
Ceci quand je peux et utilise @ Convention de soulignement d'unholysampler . D'accord sur quelque chose avec vos collègues et mettez-le dans vos normes de codage.
doSomething(this);
En ce qui concerne le dernier point que vous faites, par votre logique, en utilisant privé est redondant dans chaque cas d'utilisation possible, car toute déclaration serait "correcte" sans cela - et pourtant vous l'avez utilisé Dans la valeur Déclaration de champ. Je ne dis pas que je recommande d'utiliser Ceci. Dans le contexte d'invocation de la méthode, je souligne simplement que vous contredisez votre propre raisonnement.
Utilisation de cela.Method () au lieu de la méthode () est redondant car il compile le même code de bytecode / machine, toute raison de le faire est purement stylistique.
Cependant, le marquage d'une variable que la VS privée protégée cache la variable des classes héritées, qui est dans de nombreux cas nécessaires.
Il est techniquement ambigu, sauf dans le cas où vous avez une observation variable (que Jigar a souligné dans sa réponse).
Le plus souvent si vous travaillez dans un éditeur / IDE qui est très conscient de la mise en surbrillance de votre structure de classe STRUCTURE, il est évident que la variable est de savoir si une variable est de champ dans l'objet ou simplement une variable définie dans une méthode. Cependant, dans des éditeurs de texte plus purs (VIM, par exemple), la surbrillance de la syntaxe ne rend pas cela clair.
avec cela dit, je préfère utiliser ce fichier.field pour désigner tous les champs appartenant à l'objet si seulement parce que je sais que de temps en temps, je vais lire du code en dehors de mes idées normales. C'est marginalement plus verbeux, mais c'est un compromis que cela ne me dérange pas.
Dans votre question, les deux premiers échantillons ont exactement la même chose. Le seul où maintenant je ne pense pas qu'il y ait une meilleure pratique absolue, surtout que Les ID modernes fournissent une surbrillance de la syntaxe avancée. Certains aiment préfixer l'attribut avec quelque chose comme ce est obligatoire est le moment où un attribut est ombré par une variable locale: _ , m _ , etc., etc. et ne pas utiliser ceci . Certains préfèrent faire l'utilisation de ce obligatoire et ne pas ajouter de règles de nommage sur les attributs. Ce que vous allez faire est de vaste en fonction du code existant ou des normes de codage existantes. Je n'existe rien de veiller à ce que les normes de codage soient les mêmes pour toutes les personnes travaillant sur le projet.
Notez que les deux approches ne sont pas seulement semblent d'avoir le même effet - ils le font réellement.
ceci. est impliqué lors de l'accès des membres d'instance, et le bytecode compilé sera identique pour la syntaxe.""cette. est implicite "... et le bytecode compilé sera identique pour la syntaxe" - OOOOOOOOH :)