IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles sont les bonnes conventions d'écriture pour Java SE 6.0 ?

Le , par ze_corsaire

22PARTAGES

0  0 
Bonjour,

J'aimerais savoir si quelqu'un a connaissance de recommandation, préconisations dans le cadre de la programmation java en 1.6.
Je recherche un doc du type http://java.sun.com/docs/codeconv/Co...onventions.pdf un peu plus à jour, préconisant par exemple l'utilisation des boucles for améliorées, la pratique de l'autoboxing (ou pas), pour des raisons de perf, de lisibilité ou d'homogénéisation.

Merci.

______

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de gifffftane
Membre émérite https://www.developpez.com
Le 18/08/2009 à 13:08
À ma connaissance cela n'existe pas ; tout le monde suit 90% de ces recommandations ou essaie. Seulement 5% parvient à suivre la recommandation principale : Donne-toi n'importe quelles règles, mais suis-les.

Il me semble que la pratique s'oriente aujourd'hui vers l'usage d'outils style PMD, qui enregistre quantité de règles d'écriture, et font autant de warning quand au code qui ne les respectent pas. Ces outils rendent de grands services, et sont configurables à l'infini.

Et sur un cas particulier tu peux demander l'avis d'autres ici même.
0  0 
Avatar de Yomhgui
Membre régulier https://www.developpez.com
Le 18/08/2009 à 13:56
Sun a en effet édicté des règles de bases mais tu peux largement les enrichir en fonction de contraintes propre à ton activité. Si tu cherches des exemples, divers projets open-source publient leur règles de codage (voir les site d'apache, d'eclipse...).

En parlant d'eclipse, si c'est l'IDE que tu utilises, il existe un bon plug-in qui permet d'intégrer la vérification des règles au développement à l'adresse http://eclipse-cs.sourceforge.net/. De nombreuses règles de base sont déjà configurées (plus complètes que celles de Sun si ma mémoire est bonne), la configuration est simple et il est possible d'écrire ses propres règles.
0  0 
Avatar de verbose
Membre éclairé https://www.developpez.com
Le 18/08/2009 à 16:00
Tu peux aussi tenir compte des évolutions apportées par d'autres langages

http://codemonkeyism.com/generation-java-programming-style/
0  0 
Avatar de ipingu
Membre habitué https://www.developpez.com
Le 18/08/2009 à 16:28
Citation Envoyé par verbose Voir le message
Tu peux aussi tenir compte des évolutions apportées par d'autres langages

http://codemonkeyism.com/generation-java-programming-style/
Très sympa ce site, de bonnes pratiques expliquées.
0  0 
Avatar de gifffftane
Membre émérite https://www.developpez.com
Le 18/08/2009 à 18:32
Ah je suis bien content de voir que les attributs publics et final trouvent un intérêt !

Il y a quelques temps j'avais eu une discussion sur ce forum pour dire que je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter, on m'avait bien sûr fait remarquer que c'était pas prudent, voire pas normal, ou pire déconseillé, et je vois qu'une tendance est en train de se faire jour en ce sens, merci les américains !

Je fiche immédiatement ce site sur ma page netvibes.
0  0 
Avatar de entreprise38
Inactif https://www.developpez.com
Le 18/08/2009 à 19:26
codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose

Sinon, comme ça a été cité : CheckStyle, aussi dispo en plugin pour Eclipse et NetBeans (centres de mise à jour NetBeans pour CheckStyle 1 : http://www.sickboy.cz/checkstyle/aut...autoupdate.xml, et CheckStyle 2 : http://www.sickboy.cz/checkstyle/aut...toupdate-2.xml)
Une merveille.
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 18/08/2009 à 19:49
Salut,

Citation Envoyé par gifffftane Voir le message
Il y a quelques temps j'avais eu une discussion sur ce forum pour dire que je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter, on m'avait bien sûr fait remarquer que c'était pas prudent, voire pas normal, ou pire déconseillé, et je vois qu'une tendance est en train de se faire jour en ce sens, merci les américains !
Je paries que tu as eu ce débat avec moi !

Perso je vois très peu d'intérêt à cela... si ce n'est de limiter l'évolution du code !

Citation Envoyé par entreprise38 Voir le message
codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
+1
Je vois très peu d'intérêt dans tous cela, mis à part pour les remarques #1 concernant final et #5 sur les interfaces...

a++
0  0 
Avatar de Yomhgui
Membre régulier https://www.developpez.com
Le 18/08/2009 à 19:59
Ah je suis bien content de voir que les attributs publics et final trouvent un intérêt !
Les attributs certes, mais l'article évoque tout un tas d'autres éléments importants qui peuvent être finalisés. Un code est clean, je pense, quand tous les éléments qui le composent ont la portée minimum qu'ils peuvent avoir. C'est vrai pour la portée au sens accessibilité (public, private, etc...) mais aussi pour la modifiabilité et l'extensibilté. Donc tout ce qui peut être final dans du Java devrait l'être, i.e.:
  • Les attributs des classes qui sont invariants,
  • Les variables locales qui ne sont pas réaffectées,
  • Pour les paramètres de méthodes, la question ne se pose pas, il devraient toujours l'être,
  • Les classes qui ne sont pas dérivées (i.e. si on veut être aussi rigoureux que possible, toutes les classes qui ne sont pas abstraites ; si, si, c'est toujours possible),
  • Toutes les méthodes qui ne sont pas "Overridées".


Et, comme par un effet du hasard, les IDE peuvent souvent rajouter les mots clef final pour nous partout où c'est possible.

je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter
Ça, ça dépend des cas à mon sens. masquer des attributs peut avoir une signification sémantique. Mais quoi qu'il en soit, utiliser un getter pour lire un attribut final est effectivement inutile et contre-productif.

codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
Pas tout à fait d'accord. Cet article propose quelques éléments méthodologiques tout à fait pertinents, à l'exclusion du point 2 qui est de nature à faire faire beaucoup trop d'opérations d'allocation inutiles. Le point 3 peut quand à lui être complété ; parcourir une liste en y appliquant un filtre, ça se fait en créant un itérateur sur celle-ci.
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 18/08/2009 à 20:42
Salut,

Citation Envoyé par Yomhgui Voir le message
  • Les attributs des classes qui sont invariants,
  • Les variables locales qui ne sont pas réaffectées,
+1
Citation Envoyé par Yomhgui Voir le message
  • Pour les paramètres de méthodes, la question ne se pose pas, il devraient toujours l'être,
Pas forcément, perso j'utilise parfois quelque chose du style :
Code : Sélectionner tout
1
2
3
4
5
6
7
public void method(MyObject value) {
    if (value == null) {
        value = DEFAULT_VALUE;
    }

    // utilisation de "value" qui n'est jamais null
}
Mais bon là je chipote

Citation Envoyé par Yomhgui Voir le message
  • Les classes qui ne sont pas dérivées (i.e. si on veut être aussi rigoureux que possible, toutes les classes qui ne sont pas abstraites ; si, si, c'est toujours possible),
  • Toutes les méthodes qui ne sont pas "Overridées".
Là par contre je ne suis pas d'accord ! On casse toutes les possibilités d'évolutions pour rien

Citation Envoyé par Yomhgui Voir le message
Ça, ça dépend des cas à mon sens. masquer des attributs peut avoir une signification sémantique. Mais quoi qu'il en soit, utiliser un getter pour lire un attribut final est effectivement inutile et contre-productif.
Cela permet de cacher l'implémentation.

a++
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 18/08/2009 à 22:17
Citation Envoyé par Yomhgui Voir le message

Ça, ça dépend des cas à mon sens. masquer des attributs peut avoir une signification sémantique. Mais quoi qu'il en soit, utiliser un getter pour lire un attribut final est effectivement inutile et contre-productif.

La tu pense programmation fonctionnelle et non programmation objet. C'est le principe même de l'encapsulation. T'as pas a savoir ce que fait l'instance qu'on te passe en interne ni comment elle le fait. Donc un getter est utile dans la pluspart des cas. Personellement, les seule cas ou je les outrepasse, ce sont les cas ou j'ai des garantie de controle total, par exemple quand l'attribut en question est sur une static inner class non visible de l'extérieur et que l'objet en question n'est qu'un support de donnée entre des appels de méthode.

Quand au mot clé final sur les méthodes, avec un telle pratique, bonne chance lorsque tu gèrera des projets avec de nombreux sous projet. Quand le projet X aura besoin de faire une sous classe de Y pour une raison quelconque et que pour ça faut modifier le projet Y mais que le projet Y il est géré par un autre équipe et que l'équipe en question peut pas te faire une release stable de la dernière version de Y avant dans 3 semaine et que ton projet X doit être fini dans 2 semaines.... Tu va finir avec un fork de Y spécialement pour ton projet avec juste un mot clé retiré... Et ce our chaque librairie ou le problème se rencontrera :s

Honnêtement, y a rien de plus pénible que de tomber sur une méthode final que t'as besoin d'écraser dans une librairie sur laquelle t'as pas le controle.

Je connais pas beaucoup de méthode final dans l'api de sun. Il y en a partout sur Vector. Combien de fois j'ai pas entendu des programmeur autour de moi raler parce qu'il ne pouvaient pas hériter de Vector ....
0  0