Utilisation de traits de soulignement dans Java variables et noms de méthode
Même de nos jours, je vois souvent des traits de soulignement dans Java, un exemple sont les variables membres (comme "m_count" ou "_count"). Pour autant que je m'en souvienne, utiliser des traits de soulignement dans ces cas est appelé mauvais style par Sun.
Le seul endroit où ils doivent être utilisés est dans les constantes (comme dans "public final static int IS_OKAY = 1;"), car les constantes doivent être en majuscules et non en chameau. Ici, le trait de soulignement devrait rendre le code plus lisible.
Pensez-vous que l'utilisation de traits de soulignement dans Java est un mauvais style? Si oui (ou non), pourquoi?
Si vous n'avez pas de code l'utilisant maintenant, je vous suggère de continuer. Si votre base de code l'utilise, continuez.
La plus grande chose à propos du style de codage est cohérence. Si vous n'avez rien de cohérent, les recommandations du fournisseur de langue sont probablement un bon point de départ.
sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs (); [.________.
Règles:
- Faites ce que fait le code que vous éditez
- Si # 1 ne s'applique pas, utilisez camelCase, pas de soulignement
Je ne pense pas que l'utilisation de _ ou m_ pour indiquer les variables membres est mauvaise en Java ou tout autre langage. Cela, à mon avis, améliore la lisibilité de votre code car il vous permet de regarder un extrait et identifier rapidement toutes les variables membres des sections locales.
Vous pouvez également y parvenir en forçant les utilisateurs à ajouter des variables d'instance avec "this", mais je trouve cela un peu draconien. À bien des égards, il viole DRY parce que c'est une variable d'instance, pourquoi la qualifier deux fois.
Mon style personnel est d'utiliser m_ au lieu de _. La raison étant qu'il existe également des variables globales et statiques. L'avantage de m _/_ est qu'il distingue une étendue de variables. Vous ne pouvez donc pas réutiliser _ pour global ou statique et je choisis respectivement g_ et s_.
Le "mauvais style" est très subjectif. Si certaines conventions fonctionnent pour vous et votre équipe, je pense que cela qualifiera un mauvais/bon style.
Pour répondre à votre question: j'utilise un trait de soulignement de début pour marquer les variables privées. Je le trouve clair et je peux parcourir rapidement le code et découvrir ce qui se passe.
(Cependant, je n'utilise presque jamais "ceci", sauf pour éviter un conflit de noms.)
l'utilisation de 'm_' ou '_' à l'avant d'une variable facilite le repérage des variables membres dans les méthodes d'un objet.
Comme avantage secondaire, taper 'm_' ou '_' fera apparaître intellsense en premier;)
Il y a une raison pour laquelle l'utilisation de soulignements était considérée comme un mauvais style dans le passé. Lorsqu'un compilateur d'exécution était inabordable et que les moniteurs étaient dotés d'une résolution étonnante de 320 x 240 pixels, il n'était souvent pas facile de faire la différence entre _name et __name.
- Il se trouve que j'aime les soulignés principaux pour les variables d'instance (privées), il semble plus facile à lire et à distinguer.Bien sûr, cette chose peut vous causer des problèmes avec les cas Edge (par exemple, les variables d'instance publiques (pas communes, je sais) - de toute façon vous nommez vous les brisez sans doute votre convention de dénomination:
private int _my_int; public int myInt;? _my_int? )
-autant que j'aime le _style de ceci et que je pense que c'est lisible, je trouve que c'est sans doute plus de problèmes que cela en vaut la peine, car c'est rare et il est probable qu'il ne correspond à rien d'autre dans la base de code que vous utilisez.
-la génération de code automatisée (par exemple, les getters de génération d'Eclipse, les setters) ne sont pas susceptibles de comprendre cela, vous devrez donc le réparer à la main ou avec suffisamment d'Eclipse pour le faire reconnaître.
En fin de compte, vous allez à l'encontre du reste des préférences du monde (Java) et êtes susceptible d'en avoir quelques ennuis. Et comme les affiches précédentes l'ont mentionné, la cohérence de la base de code l'emporte sur tous les problèmes ci-dessus.
Voici un lien vers les recommandations de Sun pour Java. Non pas que vous deviez les utiliser ou même que leur code de bibliothèque les suive tous, mais c'est un bon début si vous partez de zéro. Des outils comme Eclipse ont intégré des formateurs et des outils de nettoyage qui peuvent vous aider à vous conformer à ces conventions (ou à d'autres que vous définissez).
Pour moi, '_' est trop difficile à taper :)
C'est bien d'avoir quelque chose pour distinguer les variables privées des variables publiques, mais je n'aime pas "_" dans le codage général. Si je peux l'aider dans le nouveau code, j'évite leur utilisation.
C'est un mélange de styles de codage. Une école de pensée consiste à faire précéder les membres privés d'un trait de soulignement pour les distinguer.
setBar( int bar)
{
_bar = bar;
}
au lieu de
setBar( int bar)
{
this.bar = bar;
}
D'autres utiliseront des traits de soulignement pour indiquer une variable locale temporaire qui sera hors de portée à la fin de l'appel de méthode. (Je trouve cela assez inutile - une bonne méthode ne devrait pas être aussi longue, et la déclaration est juste là! Donc je sais que cela sort du champ d'application) ! Ce serait l'enfer.
Parfois, le code généré fera précéder les variables de _ ou __. L'idée étant qu'aucun humain ne ferait jamais cela, donc c'est sûr.
La raison pour laquelle les gens le font (d'après mon expérience) est de différencier les variables membres et les paramètres de fonction. Dans Java vous pouvez avoir une classe comme celle-ci:
public class TestClass {
int var1;
public void func1(int var1) {
System.out.println("Which one is it?: " + var1);
}
}Si vous avez créé la variable membre _var1 ou m_var1, vous n'auriez pas l'ambiguïté dans la fonction.
C'est donc un style a, et je ne dirais pas que c'est mauvais.
Je pense que tout style qui rompt les propres directives de style d'une langue (sans raison valable) est moche et donc "mauvais".
Sans aucun doute, le code que vous avez vu a été écrit par quelqu'un qui travaillait sur une langue où les soulignements étaient acceptables.
Certaines personnes ne peuvent tout simplement pas s'adapter aux nouveaux styles de codage ...
Personnellement, je pense qu'un langage ne devrait pas faire règles sur le style de codage. C'est une question de préférences, d'utilisation, de commodité, de concept de lisibilité.
Maintenant, un projet doit définir des règles de codage, pour la cohérence entre les listes. Vous n'êtes peut-être pas d'accord avec ces règles, mais vous devez vous y tenir si vous voulez contribuer (ou travailler en équipe).
Au moins, les IDE comme Eclispe sont agnostiques, permettant de définir des règles comme les préfixes ou suffixes variables, divers styles de placement d'accolade et de gestion de l'espace, etc. Vous pouvez donc l'utiliser pour reformater le code selon les directives vos.
Remarque: Je fais partie de ceux qui gardent leurs anciennes habitudes de C/C++, codant Java avec m_ préfixes pour les variables membres (et s_ pour les variables statiques), préfixant les booléens avec un b initial, en utilisant un initial lettre majuscule pour les noms de fonction et alignement des accolades ... L'horreur pour Java fondamentalistes! ;-)
Curieusement, ce sont les conventions utilisées là où je travaille ... probablement parce que le principal développeur initial vient du monde MFC! :-RÉ
c'est juste votre propre style, rien de mauvais code de style, et rien de bon code de style, faites simplement la différence entre notre code et les autres.