Outils pour utilisateurs

Outils du site


public:travail_collaboratif:principes_code

Principes d'écriture du code

Liste des principes d'écriture de code.

Eclipse

Java

Généralement se conformer aux principes Java et aux propositions d'Eclipse :

Précisions pour les cas auxquels on tient plus particulièrement et exemples pour se faire une idée rapidement sans avoir à parcourir toutes les guidelines :

blocs

Mettre autant de brackets que possible.

Formatage :

if (test) {

}

La forme inlinée if (test) { return false;} peut suffire mais seulement en début de méthode

Groovy

Les principes généraux : http://groovy-lang.org/semantics.html

Quand Groovy ne définit pas de principe pour un point particulier, il hérite de celui de Java.

Ne pas mettre de point virgules en fin de statement.

Discussion des nouvelles pratiques

  • configuration des environnements de dev proches voire identiques
    • Partager la configuration du workspace Eclipse :
  Text file encoding : UTF-8
  New text file line delimiter : Unix
  Java > Editor > Save Actions : activer les actions : "format" (et "organize" ?)
  Java > Compiler : Compiler compliance settings : 1.8
  Java > Installed JREs :  "Linux TXM JRE" ou  "Windows TXM JRE" ou "MacOSX TXM JRE" (Oracle jre 1.8)
  • Développer le test unitaire pour vérifier la configuration des projets : MD

Page “Java compiler” de “Projet\Properties” :

          désactiver "Enable project specific settings"
      Page "Java build path\Libraries" de "Project\Properties" :
          Editer la JRE utilisée et mettre "Workspace Default JRE"
          Bien sûr, il faut régler avant la JRE du Workspace par défaut en mettant celle qu'on embed dans TXM
  * Partager des workings sets -> difficile dans l'état, export/import compliqué
    * dans workingsets.xml de .metadata/.plugins/org.eclipse.ui.workbench du workspace Eclipse
  * Partager un fichier de règles de formatage Java
    * appliquer le formatter à la sauvegarde d'un fichier (évite d'être surpris par le formatter)
  * localisation des fichiers de travail ou property system partagé
* discussions/décisions à plusieurs quand enjeux forts/moyens
  * évaluer l’enjeu ? dès qu'on touche au code de %%org.txm.core%% ? dès qu'on touche à un plugin dont dépendent plus de 2 plugins ?
* faire l'état des lieux des libs non utilisées et si possible retrouver les numéros de version de celles utilisées + licence, etc.
* afficher correctement les numéros de version et les licences
  * ajouter une phase dans le cycle de publis pour la publication de nouvelles libs
* duplication / mutualisation / abstraction
* casts à outrance 
* blocs test sur une ligne et bloc test dans accolades
* membre statiques en début de classe + noms tout en majuscules
* nom de variable Java => convention Java = minuscule en début de nom et ensuite 1re lettre de chaque mot en majuscule : mpart = bad, mPart = good, targetpos = bad, targetPos = good
  * gestion des pluriels dans les noms de variable
* review du code après commit ? succincte/totale
  * rétablir les mails de commits
* tests plus poussés avant commit
* commentaires dans le code
* javadoc des classes et méthodes
  * niveau 1 : développer level = informations utiles pour utiliser la classe dans le code de TXM
  * niveau 2 : API level = logique générale de l'API et informations complètes sur l'utilisation
  * niveau 3 : Groovy level = exemples d'appel Java ou Groovy

Notes/propositions supplémentaires SJ

  • privilégier l'utilisation de NLS.bind() lors de la création de chaînes de caractères pas encore externalisées ou qui ne seront pas externalisées plutôt que la concaténation avec le symbole “+” ?
    
    PDF de Serge
    Chantiers :
Eclipse/Ant → Maven/Tycho
build plus automatisé
SVN → GIT
liens automatiques git-push (svn-commit) <→ tickets ?
Gitlab
CI-CD
tickets utilisateurs eduGAIN (Renater)
portail / poste
org.txm.ui + org.txm.rcp + org.txm.rap
Ordre du jour :
hébergements
code
versionnage (svn, git…)
répertoires
dossiers SVN
projets Eclipse
nom du projet
dossier du projet
packages Java
des retours
des tickets utilisateurs VS développeurs ?
du site web et des ressources (cf nouveau site à l'IN2P3)
organisation du travail
campagne de développement 2018-2019 (bilan)
campagne de développement 2019-2020
principes et outils de travail
tests, builds, majs et setups automatiques
format du code
javadoc niveau II
javadoc niveau III Groovy
chantiers / projets de développements : implications, planification…
applications
RCP
Portail
architecture
mise à jour
partielle (plugin par plugin)
BUG : une extension ne met pas à jour le tronc pour ses propres besoins
modèles de données
représentations d'annotations
stand-off / inline
fonctionnalités
optimisation
diagnostic, audit
point de vue fonctionnel (utilisateur)
ce qui est lent
démarrage
certains calculs
sauvegarde des annotations
point de vue composants (interne)
ergonomie
rendre compte de l'activité
ce qui est lent : démarrage, certains calculs
relations entre partenaires
valorisation, diffusion, dissémination
etc.
public/travail_collaboratif/principes_code.txt · Dernière modification: 2019/10/17 10:29 par matthieu.decorde@ens-lyon.fr