Discussion :

[ze_corsaire]

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/CodeConventions.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.

______

[gifffftane]

À 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.

[Yomhgui]

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.

[verbose]

Tu peux aussi tenir compte des évolutions apportées par d'autres langages

http://codemonkeyism.com/generation-...ramming-style/

[ipingu]

Tu peux aussi tenir compte des évolutions apportées par d'autres langages

http://codemonkeyism.com/generation-...ramming-style/

Très sympa ce site, de bonnes pratiques expliquées.

[gifffftane]

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.

[Benouze]

[Edit Ricky81](suite à fusion, ne blamez pas l'auteur ;-) [/Edit]

Bonjour,

Ci-après un billet de Stephan Schmidt tiré de son blog.

Vos opinions ?

Many companies and developers move away from Java to new languages: Ruby, Python, Groovy, Erlang, Scala. You might be trapped with Java.

Even if you’ve trapped, you can change your programming style and reap some of the benefits of those new languages. In the last 15 years Java programming style has changed significantly:

1. Final is your new love: More and more Java developers in the teams I’ve worked with, started to use final. Making variables final prevents changing those values. Most often, if you reasign a value, it’s a bug or you should use a new variable. Final prevents bugs and makes code easier to read and understand. Make everything immutable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

      final Foo bar = new Foo();

I’ve written more about this topic in “All variables in Java must be final”.

2. No setters. Many Java developers automatically – sometimes with the evil help of an IDE – write setters for all fields in their classes. You should not use setters. Think about each setter you want to write, are they really necessary for your fields? Better create new copies of your objects if values change. And try to write code without getters either. Tell, don’t ask tells you more about the concept.

3. Do not use loops for list operations. Learning from functional languages, looping isn’t the best way to work on collections. Suppose we want to filter a list of persons to those who can drink beer. The loop versions looks like:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
      List<Person> beerDrinkers = new ArrayList<Person>();
      for (Person p: persons) {
          if (p.getAge() > 16) {
      	    beerDrinkers.add(p);
          }
      }

This can – even in Java – be rewritten to a more a functional programming style. For example using Google collections filter:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
      Predicate<HasAge> canDrinkBeer = new Predicate<HasAge>() {
          public boolean apply(HasAge hasAge) {
              return hasAge.getAge() > 16;
          }
      };
 
      List<Person> beerDrinkers = filter(persons, canDrinkBeer);

As remarked by Dave Jarvis, I should have dropped the getter, and he’s right ;-)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
      Predicate canDrinkBeer = new Predicate() {
           public boolean apply(HasAge hasAge) {
               return hasAge.isOlderThan( 16 );
          }
      };

which would lead to better code down the road:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
      Predicate canDrinkBeer = new Predicate() {
          public boolean apply( HasAge hasAge, HasAge otherAge ) {
              return hasAge.isOlderThan( otherAge );
          }
      }

The predicate version is slightly larger, but consists of two parts. Each one is easier to understand. While the loop version gets unreadable fast with new requirements, the functional version can easily be combined,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

      List beerDrinkers = filter(filter(persons, canDrinkBeer), isMale);

More on this at the Metaphysical Developer.

4. Use one liners: Write concise code. Java is a noisy language. But don’t make it noiser as it needs to be. Instead of

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
      public int add(int a, int b)
      {
        int result = a + b;
        return result;
      }

write

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
      public int add(int a, int b) { return a + b; }

IDEA and possibly other IDEs can keep oneliners formatted as oneliners, if you tell them so.

5. Use many, many objects with many interfaces. Domain driven design currently makes a big splash. A class should be splitted into many roles, implementing many interfaces. This way the class is reusable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
      public class Person implements Nameable, Hireable, LivesAt {
         ...
      }
 
      public interface Nameable {
        String getName();
      }
 
      Methods should be written to only work on roles, not classes. This way methods can work on more objects. Another benefit is lower coupling.
 
      public void print(Nameable name) {
        System.out.println(name.getName());
      }

I’ve written more about that in “Never, never, never use String in Java “.

6. Use Erlang-Style Concurrency. The Java concurrency primitives like locks and synchronized have been proven to be too low level and often to hard to use. There are better ways to write concurrent code. Erlang Style concurrency is one of them – in Java there are many ways to achive this in Java – I’ve written about them here. Newer ones are Akka and Actorom. You can also use Join/Fork or the myriad of data structures in java.util.concurrent.

7. Use Fluent Interfaces. Fluent interfaces can make your code much more readable and shorter. A very good example is the MapMaker API in Google Collections:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
       ConcurrentMap graphs = new MapMaker()
             .concurrencyLevel(32)
             .softKeys()
             .weakValues()
             .expiration(30, TimeUnit.MINUTES)
             .makeComputingMap(
                 new Function() {
                   public Graph apply(Key key) {
                     return createExpensiveGraph(key);
                   }
                 });

8. Data Transfer Objects without setters and getters. If you have simple data holders or data transfer objects, don’t write boiler plate code with getters and setters. I know this is heresy in Java, but just use public fields. Instead of

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
      public class Point {
         private int x;
         private int y;
 
         pulic Point(int x, int y) {
            this.x = x;
            this.y = y;
         }
         public int setX(int newX) {
            x = newX;
         }
         public int getX() {
           return x;
         }
         ...
      }
      ...
      int x = p.getX();
      int y= p.getY();

write

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
      public class Point {
         public final int x;
         public final int y;
 
         pulic Point(int x, int y) {
            this.x = x;
            this.y = y;
         }
      }
      ...
      int x = p.x;
      int y = p.y;

Refactoring is easy, should you need it. If you do not control all the code and it’s usage, you might need to be more careful though.

This tips lead to better Java code. Try them in your next Java class. What do you think? I’d like to hear how your Java coding style has changed in the last 10 years.

Update: Some thoughts to Cedrics thoughts.

As the author of the post, your thoughts are appreciated, some of mine:

“Besides, it’s convenient to be able to mutate object if you want to use pools.”

No setters doesn’t mean you can’t mutate objects, it’s just that plain setters are not object oriented thinking. How about stop() vs. setStop(true);

“I think the first example is more readable than the second one that uses Predicates.”

[nouknouk]

Mouais,

il y a quand même quelques points avec lesquels je ne suis pas d'accord du tout. En fait tout dépend du projet (voire de la partie du projet) sur lequel on bosse et les priorités qu'on se donne (flexibilité, réutilisabilité, performance, clarté du code, ...).

Balancer des règles sans préciser le contexte, laissant penser qu'une règle est toujours valable dans tous les cas, est amha une erreur courante du niveau du développeur moyen à la recherche de LA réponse universelle. En développement comme dans beaucoup d'autres domaines, "choisir, c'est renoncer" comme dirait l'autre

Comme dans la vraie vie, la réalité des choses dépend fortement du contexte et des contraintes inhérentes au projet. Rien n'est jamais tout blanc ou tout noir. Quelques exemples:

- "Final is your new love": j'expériemente acutellement l'abus de ce genre de pratique dans un framework Java (pulpcore) où l'immense majorité des méthodes sont déclarées 'final'. Le résultat est que tant qu'on reste "dans les clous" de l'utilisation prévue par le concepteur, tout va bien. Mais dès qu'on veut faire quelque chose d'un peu plus spécifique, on se retrouve très vite complètement enfermé dans un carcan rigide, l'opposé même de la notion de framework. En résumé, autant ce genre de pratique peut-être bénéfique (notamment pour déceler les bugs dès l'écriture du code), autant dans le cas d'un code destiné à être réutilisé et/ou adapté (framework, librairie plus ou moins générique) ça devient vite une contrainte supplémentaire totalement inutile.

- "Do not use loops for list operations": bien que la solution proposée soit plus "élégante", la compacité et l'approche "classique" du code dans le premier exemple rend la relecture du code bien plus 'compréhensible' amha.

- "No setters" / "Data Transfer Objects without setters and getters": pas toujours: il est parfois extrêmement utile de pouvoir intercepter les appels aux getters/setters pour du debug, la POA, ou pour une classe dérivée qui veut adapter la valeur sotckée/retournée.

Tout ça pour dire que, quelles que soient les règles édictées, elle ne peuvent jamais être universelles ; Et même si elles me paraissent toutes plus ou moins pertinentes dans un contexte donné, amha son billet aurait beaucoup gagné à présenter pour chacune de ses règles leurs propres limites.

[adiGuba]

Salut,

Personnellement je trouvais que tout cela s'adapte mal au cas général, et que c'était donc franchement abusé de présenter cela comme de nouvelles règles de programmation

a++