Ecrit "ceci". avant variable d'instance et méthodes bon ou mauvais style?

Question

L'un de mes méchants (?) les habitudes de programmation en C++ et Java est toujours précéder les appels ou les accès aux membres avec un this. Par exemple: this.process(this.event).

Quelques-uns de mes étudiants a commenté sur ce point, et je me demande si je suis l'enseignement de mauvaises habitudes.

Mon raisonnement est:

1. Rend le code plus lisible plus Facile de distinguer les champs de variables locales.
2. Facilite la distinction des appels standards de la statique des appels (surtout en Java)
3. Me fait rappeler que cet appel (sauf si la cible est définitive) pourrait se retrouver sur une cible différente, par exemple dans une bonne version dans une sous-classe.

Évidemment, cela a un impact nul sur le programme compilé, c'est juste de la lisibilité. Donc suis-je en le rendant plus ou moins lisible?

Liés à la Question: avez-vous préfixe de votre variable d'instance avec " il " en java?

Note: je l'ai transformée en un CW car il n'est vraiment pas une bonne réponse.

Answer 1

Je pense que c'est moins lisible, surtout dans les environnements où les champs sont mis en évidence différemment des variables locales. La seule fois où je veux voir "ceci", c'est quand c'est nécessaire, par exemple:

 this.fieldName = fieldName
 

Lors de l'attribution du champ.

Cela dit, si vous avez besoin d'un moyen de différencier les champs pour une raison quelconque, je préfère "this.fieldName" à d'autres conventions, comme "m_fieldName" ou "_fieldName"

Answer 2

C'est quelque chose de très subjectif. Microsoft StyleCop a une règle exigeant la ce. qualificatif (même si c'est C# connexes). Certaines personnes utilisent le trait de soulignement, certains utilisent bizarre hongrois notations. Personnellement, je qualifier les membres de ce. même si elle n'est pas explicitement requis pour éviter toute confusion, parce qu'il y a des cas où il peut faire un code un peu plus lisible.

Vous pouvez également vouloir vérifier cette question:
http://stackoverflow.com/questions/111605/what-kind-of-prefix-do-you-use-for-member-variables

Answer 3

Je n'avais jamais vu ce style jusqu'à ce que j'ai rejoint mon employeur actuel. La première fois que je l'ai vu j'ai pensé "cet idiot n'a aucune idée et Java/OO langues en général ne sont pas son point fort", mais il s'avère que c'est un régulièrement survenant affliction ici et il est obligatoire de style sur quelques projets, bien que ces projets aient également utiliser l'

if (0 == someValue)
{
    ....
}

approche d'instructions conditionnelles, c'est à dire de placer la constante d'abord dans le test de sorte que vous ne courez pas le risque de l'écriture

if (someValue = 0)

par accident, un problème commun pour les C codeurs qui ignorent leurs avertissements du compilateur. Chose est, en Java ci-dessus est tout simplement le code non valide et sera chucked par le compilateur, de sorte qu'ils sont effectivement leur code moins intuitif pour aucun avantage.

Pour moi, par conséquent, loin de montrer "l'auteur est le codage avec un processus de pensée", ces choses me paraissent plus susceptibles de provenir de le genre de personne qui ne s'en tient qu'aux règles de quelqu'un d'autre a dit une fois, sans les remettre en question ou de connaître les raisons de la réglementation en premier lieu (et donc où les règles ne s'appliquent pas).

Les raisons que j'ai entendu principalement résument à "c'est la meilleure pratique" d'habitude, citant Josh Bloch est Efficace Java qui a une influence énorme ici. En fait, cependant, Bloch n'a même pas l'utiliser où même je pense qu'il devrait probablement avoir à l'aide de la lisibilité! Une fois de plus, il semble être plus le genre de chose fait par des gens qui sont dit de le faire et je ne sais pas pourquoi!

Personnellement, je suis enclin à être d'accord avec ce que Bruce Eckel dit dans la Réflexion Java (3e et 4e éditions):

---

'Certaines personnes de manière obsessionnelle à mettre cela en face de chaque appel de méthode et champ de référence, en faisant valoir qu'il est "plus clair et plus explicite." Ne pas le faire. Il ya une raison que nous utilisons des langages de haut niveau: Ils font des choses pour nous. Si vous placez ce dans quand il n'est pas nécessaire, vous risquez de perturber et d'ennuyer tout le monde qui lit votre code, puisque tout le reste du code qu'ils ont lu de ne pas utiliser ce partout. Les gens s'attendent à ce être utilisé uniquement lorsque cela est nécessaire. À la suite d'un uniforme et simple style de codage permet d'économiser du temps et de l'argent."

---

note de bas de page, p169, Penser en Java, 4e édition

Tout à fait. Moins est plus, les gens.

Answer 4

3 Raisons ( Nomex costume SUR)

1) la Normalisation des

2) la Lisibilité

3) IDE

1) Le biggie Pas partie de Sun Java code de style.

(Pas besoin d'avoir tout les autres styles de Java.)

Afin de ne pas le faire en Java.)

C'est en partie le col bleu de Java chose: c'est toujours la même partout.

2) la Lisibilité

Si vous le souhaitez.pour l'avoir.ce face à toute cette.d'autres cette.mot; avez-vous vraiment cela.pense qu'il améliore cela.la lisibilité?

Si il y a trop de méthodes ou d'une variable dans une classe pour vous de savoir si c'est un membre ou pas... refactoriser.

Vous n' avez variables de membre et vous n'avez pas de variables globales ou des fonctions en Java. ( En d'autres langunages vous pouvez avoir des indicateurs, tableau de dépassement, non des exceptions et des variables globales trop; en profiter.)

Si vous voulez savoir si la méthode est dans vos classes classe parent ou pas... n'oubliez pas de mettre @Override sur vos déclarations et laisser le compilateur vous dire si vous ne la supplante pas correctement. super.xxxx() est de style standard en Java si vous voulez appeler une méthode parent, sinon laissez le dehors.

3) IDE Quelqu'un écrire du code sans IDE qui comprend la langue et donne un aperçu sur la barre latérale peut le faire sur leur propre nickel. Se rendant compte que si elle n'est pas " la langue sensible, vous êtes pris au piège dans les années 1950. Sans interface graphique: pris au piège dans les années 50.

Toute bonne IDE ou l'éditeur va vous dire où une fonction/variable est de. Même l'original VI (<64 ko) le ferons avec CTags. Il n'y a simplement aucune excuse pour l'utilisation de merde outils. Les bons sont gratuits!.

Answer 5

Parfois, j'aime écrire des cours comme celui-ci:

 class SomeClass{
    int x;
    int y;

    SomeClass(int x, int y){
        this.x = x
        this.y = y
    }
}
 

Cela permet de savoir plus facilement quel argument définit quel membre.