Selon le site de Sun voici les arguments pour définir des conventions de programmation .
Code conventions are important to programmers for a number of reasons:
- 80% of the lifetime cost of a piece of software goes to maintenance.
- Hardly any software is maintained for its whole life by the original author.
- Code conventions improve the readability of the software, allowing engineers to understand -new code more quickly and thoroughly.
- If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.
Je suis absolument d'accord avec ces propos, c'est pour cela que je respecte un certain nombres de conventions quand je programme en Java. Toute organisation devrait aussi avoir son propre manuel de conventions pour :
- centraliser l'information
- prendre des décisions claires quand les ambiguités peuvent exister
- les étendre pour mieux répondre à leur besoin
Et tout cela dans un but :
- rendre homogène les développement de différents programmeurs ou équipes
- rendre la maintenance plus facile
- ... et bien d'autres avantages encore...
Il existe plusieurs points de départ pour définir ses propres conventions Java:
- les conventions présentement utilisées
- les conventions de Sun
- autres
Beaucoup d'entreprises, quand elles ont migré à Java, ont pris leurs conventions C++ et les ont adaptées à Java. Personnelement, je n'aime pas cette pratique. Java est un langage qui a su repartir d'une feuille blanche. A l'instar du C++ qui voulait à tout pris garder une compatibilité avec le C, Java n'avait aucune contrainte de cet ordre. C'est en grande partie pour cette raison que Java est un langage simple et stable. Pour les conventions et normes, je pense que ça devrait être la même chose. Sun avec le lancement de Java a fait une proposition de règles de programmation qui est grandement acceptée, alors il ne reste qu'à la suivre et au besoin l'adapter quelque peu et surtout l'étendre pour mieux répondre aux besoins de votre organisation.
Dans ce site, je présente les conventions que j'utilise dans mes mandats en tant qu'ingénieur consultant en informatique.
Dans les projets dans lesquels j'interviens, je ne peux en général pas changer les normes déjà établies. C'est pour cela que je présente ici un 2ème niveau de normes qui en général est inexistant. Ce sont des règles de nommages de classes, de méthodes, de packages qui en général ne rentrent pas en conflit avec les normes des sociétés pour lesquelles j'effectue des mandats.
De plus, une section "Liens - Ressources" liste un certains nombres de liens sur des sites présentant des conventions. Ça peut des sites de référence comme celui de Sun ou des pages personnelles... Comme je le disait, il n'existe aucune norme ou convention absolue, les exemples présentés peuvent donc être contradictoires mais cela ne signifit pas que ce sont pour autant des mauvaises pratiques, à vous de décider...
Pour ma part, tous les exemples que je présente s'inspire fortemet des conventions de Sun.