Author: Bob Jacobsen
Keywords: JMRI technical code standards recommendation Swing

# JMRI: Pratiques Recommandées

Voici la page d'infos diverses et des pointeurs pour les développeurs JMRI.

## Class Library Preferences

- Nous utilisons Java Swing pour notre développement de l'Interface Graphique Utilisateur (GUI). Il est beaucoup plus puissant que l'AWT d'origine, et le prix est juste. Nous avons recommandé un modèle d'organisation et d'utilisation qui est documenté sur une autre page.
- JMRI utilise les bibliothèques RXTX pour soutenir les communications série sur Macintosh, Linux et Windows. Sous Windows uniquement, le paquet de Serialio Serialio.com est également utilisé pour être en mesure d'utiliser la vitesse de transmission MS100. Pour ce faire, la classe jmri.jmrix.loconet.ms100.MS100Adapter a été convertie pour utiliser la réflexion de Java pour décider si le paquet Serialio est disponible; sur d'autres systèmes, il utilise RXTX. Notez que notre licence de Serialio est limitée à ce seul usage; nous ne sommes pas autorisés à distribuer les bibliothèques à d'autres fins.
- Prenez quelques instants pour en apprendre davantage sur les types différents de collections Java qui sont disponibles (Liste, HashMap, etc) dans le paquet java.util. Tout ne doit pas être un Vecteur ou un tableau.
- JMRI utilise largement les génériques Java pour réduire les erreurs et améliorer la compréhension. Avec beaucoup de gens qui écrivent et partagent le code, à l'aide de génériques au lieu de casts, rend beaucoup plus facile la compréhension du code, et permets au compilateur de corriger de nombreux malentendus sur la façon dont les choses devraient être utilisées. La plupart des informations importantes à leur sujet peuvent être trouvées sur cette page du Tutoriel Java.
- Si vous avez besoin d'utiliser les fichiers de variables séparées par des virgules (CSV), s'il vous plaît utiliser les API Apache Commons CSV si possible. Nous utilisons déjà, dans un certain nombred'endroit, et probablement l'utiliser plus. Si cela ne donne pas suffisamment de fonctionnalités, nous pourrions éventuellement passer à l' API opencsv, mais comme nous voulons n'en utiliser qu'un la conversion demandera beaucoup de travail.

## Format du Code

Les Conventions Code Java pour les noms, mise en forme, etc sont vraiment utiles. Si vous trouvez que vous ne pouvez pas lire un morceau de code, ceux-ci vous aideront à mieux faire.

Notez que nous avons quelques conventions locales au-delà de celles qui sont dans les recommandations Java. Vous les trouverez sur d'autres pages dans cette section, mais par exemple, nous recommendons que vous définissiez le référence de journalisation en bas de chaque fichier.

## Code Obsolète

Comme le développement se poursuit, parfois d'anciennes façons de faire les choses doivent être remplacées par de nouvelles façons. Dans de nombreux cas, vous pouvez simplement changer tout le code utilisé dans votre répertoire et avancer. Pour les interfaces générales qui pourraient être utilisés à l'extérieur de JMRI, comme dans les scripts et les CATS, il peut être bon de laisser l'ancienne interface en place pendant un certain temps, en la marquant comme "obsolète" de sorte que les gens peuvent découvrir qu'elle finira par disparaître. Après un nombre suffisant de cycles de parution, l'Interface obsolète peut alors être retirée.

Notez que l'interface obsolète est destinée à travailler encore. Obsolète devrait seulement dire que vous ne pouvez pas compter sur l'interface obsolète pour travailler à l'avenir, de sorte qu'il serait bon de coder ailleurs, pendant que ça fonctionne toujours.

Vous pouvez travailler avec les contrôles relatifs à l'obsolescence "on" lors de la compilation. Pour ce faire, changez cette ligne de build.xml: `<property name="deprecation" value="on" />` Cela vous permet d'être attentif aux nouveaux avertissements de désapprobation quand vous codez.

Il existe deux formes pour marquer quelque chose comme obsolète (tag Javadoc et Annotation), et tous deux vous permettent d'ajouter des informations supplémentaires. Une belle discussion des techniques est ici. Nous les utilisons de cette façon: `* @ Deprecated 2.7.8 @ Deprecated // 2.7.8` où la ligne contenant la version dans laquelle la dévalorisation est appliquée. Cela vous permet de savoir facilement depuis combien de temps elle a été désapprouvée.