Developpez.com - Rubrique Java

Le Club des Développeurs et IT Pro

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

Le 2009-08-18 11:55:51, par ze_corsaire, Membre actif
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.

______
  Discussion forum
66 commentaires
  • gifffftane
    Membre émérite
    À 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.
    le 18/08/2009 à 13:08
  • Yomhgui
    Membre régulier
    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.
    le 18/08/2009 à 13:56
  • verbose
    Membre éclairé
    Tu peux aussi tenir compte des évolutions apportées par d'autres langages

    http://codemonkeyism.com/generation-java-programming-style/
    le 18/08/2009 à 16:00
  • ipingu
    Membre habitué
    Envoyé par verbose
    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.
    le 18/08/2009 à 16:28
  • gifffftane
    Membre émérite
    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.
    le 18/08/2009 à 18:32
  • 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.
    le 18/08/2009 à 19:26
  • adiGuba
    Expert éminent sénior
    Salut,

    Envoyé par gifffftane
    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 !

    Envoyé par entreprise38
    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++
    le 18/08/2009 à 19:49
  • Yomhgui
    Membre régulier
    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.
    le 18/08/2009 à 19:59
  • adiGuba
    Expert éminent sénior
    Salut,

    Envoyé par Yomhgui
    • Les attributs des classes qui sont invariants,
    • Les variables locales qui ne sont pas réaffectées,
    +1
    Envoyé par Yomhgui
    • 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 : 
    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

    Envoyé par Yomhgui
    • 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

    Envoyé par Yomhgui
    Ç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++
    le 18/08/2009 à 20:42
  • tchize_
    Expert éminent sénior
    Envoyé par Yomhgui

    Ç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 ....
    le 18/08/2009 à 22:17
  Poster une réponse