7
votes

Directives de classement de déclaration variable en Java

Il semble y avoir deux placements de déclaration variable acceptés pour les variables Java, chacune avec des la raison d'être .

du Conventions de code du soleil Nous pouvons voir: < / p>

Mettez des déclarations uniquement au début des blocs. (Un bloc est tout code entouré de bretelles frisées "{" et "}".) N'attendez pas de déclarer variables jusqu'à leur première utilisation; Il peut confondre le programmateur imprudent et entraver la portabilité du code dans la portée.

Cependant, dans le "Code complet" et certains autres auteurs défensent de réduire le champ d'une variable au minimum. Cela attend essentiellement de déclarer des variables jusqu'à leur première utilisation.

Ces deux approches sont clairement contradictoires bien que je puisse voir le point pour les deux.

Que dois-je suivre? Y a-t-il un consensus sur la question?


3 commentaires

Pour empêcher cela d'être «trop subjectif», je me concentrerais sur la deuxième question: Y a-t-il un consensus? D'après ce que j'ai vu, il ne semble pas y avoir, et c'est vraiment à vous et aux personnes que vous programmez.


"N'attendez pas de déclarer des variables jusqu'à leur première utilisation; il peut confondre le programmateur imprudent et entraver la portabilité du code dans la portée." est très ironique - déclarant que toutes vos variables au même endroit rendent le code moins portable. Il est plus difficile de déplacer des morceaux de chiffon total de code (peut-être à une nouvelle méthode) puisque la logique et les déclarations ne sont pas encapsulées.


Voir aussi Réponses ici: MZAN.com/article / ...


5 Réponses :


0
votes

Mon opinion personnelle est que de toute la manière est bonne. Je pense que tant que les noms de variables sont suffisamment descriptifs, cela n'a pas d'importance. Encore une fois, ce n'est que mon opinion. J'ai dû traverser beaucoup de code qui n'a pas été écrit par moi et la plus grande frustration des variables que j'ai confrontées, c'est que leurs noms ne sont pas très descriptifs. La plupart des IDes auront la possibilité de «aller à la définition» de sorte que cela ne compte pas vraiment où vous les déclarez.


2 commentaires

Semble sensible. J'adore mentionner, je voudrais, dans tous les cas, ajouter une mise en garde: pour la clarté du code et éviter toute confusion, maintenez toujours la même approche et être cohérente tout au long de votre code, sans décider de manière aléatoire où placer vos variables. De cette façon, vous perdriez les avantages de chacun.


Être obligé de "sauter à la définition" est une pause cognitive et augmente la charge de travail de quelqu'un qui tente de raisonner sur le code. J'accepte que la cohérence est importante, mais la maintenance de la capacité de raisonner sans sauter indue est essentielle.



0
votes

Ces deux déclarations n'ont pas besoin d'être contradictoires. La portée est décidée par les supports frisés, de sorte que si vous démarrez un nouvel ensemble de crochets plus près de l'endroit où vous les utilisez, c'est compatible avec la convention de codage SUN. Bien sûr, si vous ne faites que insérer arbitrairement des limitations d'étendue, c'est un problème de lecture du flux du code.

Cependant, je trouve qu'il est très important de déclarer des champs en haut de la classe, en particulier des champs mutables. La compréhension de l'état d'un objet peut être la partie la plus difficile d'une classe à long terme et la mise en place des déclarations au début de la classe indique clairement quel état important de la classe tient.


0 commentaires

1
votes

qui attend essentiellement de déclarer des variables jusqu'à sa première utilisation.

Ce n'est en fait pas vrai, et ces deux styes ne sont pas contradictoires. Limiter la portée de la variable signifie que cette variable n'existe en fait pas en dehors de cette portée. Par exemple xxx

Dans ce cas, A est une étendue limitée au bloc pour le bloc, ce que le code complet se réfère.

Dans tous les cas, je suis d'accord avec Soleil, cette variables dans une portée (classe, méthode, si bloquée, etc.) doit être déclarée au début.


1 commentaires

Si vous souhaitez minimiser la portée d'une variable dans une méthode, en général, vous ne déclarerez pas la variable au tout début. Pour cette raison, je vois vraiment que les deux directives sont conflictuelles.



0
votes

Je recommande également "Java efficace" de Joshua Bloch pour plus de raisons pour lesquelles on devrait déclarer des variables où elles sont utilisées pour la première fois.


0 commentaires

15
votes

variables devraient être déclarés aussi proches de leur utilisation que possible, pour deux raisons:

  • localité verticale
  • ASPIAGE DE L'OUTILLES

    localité verticale facilite la raison pour laquelle les morceaux de code. Moins la numérisation d'un lecteur doit faire plus facile à comprendre quel code fait et quel effets secondaires il

    Réduire la portée variable permet également de mieux ASPOIN D'OUTILLES pour des outils automatisés, tels que refactoring. Les choses les plus proches associées sont les plus évidentes qu'ils sont.

    Cela dit: Si une méthode est suffisamment longue que les points ci-dessus entrent en jeu, il est probable que la méthode est déjà trop longue et doit être refactable de toute façon.


1 commentaires

+1 pour "... Si une méthode est suffisamment longue que les points ci-dessus entrent en jeu, il est probable que la méthode est déjà trop longue ..."