Coder proprement - ch-cbna/geonature GitHub Wiki

Cette documentation est un condensé de Coder proprement - Chapitre 17

Commentaires

  • Un commentaire doit être concis et doit expliquer ce que le code est incapable d'exprimer par lui-même
  • Ne pas mettre de code en commentaire

Environnement

  • Un projet doit pouvoir se lancer en une commande

svn get mySystem cd mySystem ant all

Le "dépôt" SVN contient toutes les dernières versions de toutes les sources. Ant all expliqué ici.

  • Tous les tests unitaires doivent pouvoir se lancer à partir d'une commande (dans le meilleur des cas, à l'aide d'un bouton)

Fonctions

  • Maximum 3 arguments
  • Argument de sortie : si la fonction doit modifier un état, ce doit être celui de l’objet sur lequel elle est invoquée
  • Ne pas mettre d'indicateurs booléens en argument

Général

  • Un langage par fichier, au mieux en réduire le nombre et l'étendue
  • 100 caractères max par ligne (règle Geonature)
  • Principe de moindre surprise : toute fonction ou classe doit implémenter les comportements auxquels un autre programmeur s’attend.
  • Le code doit fonctionner dans tous les cas limites (particuliers) : implémenter des tests en conséquence
  • Pas de redondance, c'est une opportunité d’abstraction manquée.
  • Tous les concepts de haut niveau sont dans une classe de base. Tous les concepts de bas niveau se trouvent dans les classes dérivées
  • Moins la classe propose de méthodes, mieux c’est. Moins une fonction connaît de variables, mieux c’est. Moins une classe contient de variables d’instance, mieux c’est.
  • Les variables et les fonctions doivent être définies au plus près de leur utilisation. Les variables locales doivent être déclarées juste avant leur première utilisation et doivent avoir une portée verticale réduite.
  • Assurer la cohérence des nommages
  • Les méthodes d’une classe doivent s’intéresser uniquement aux variables et aux fonctions de leur classe, non à celles des autres classes.
  • Le code doit être aussi expressif que possible pour faciliter la tâche au lecteur
  • Décomposer les calculs en valeurs intermédiaires représentées par des variables aux noms significatifs.
  • Les noms des fonctions doivent indiquer leur rôle
  • Exemple de code conventionnel : (déclaration variables, nom classes, accolades...)
  • Remplacer les nombres par des constantes nommées à part si ce nombre est facilement compréhensible (ex : 2, 3.14)
  • Eviter les expressions conditionnelles négatives
  • Les fonctions doivent faire une seule chose
  • Les arguments des fonctions doivent être structurés de manière que leur ordre dans les appels soit évident. Chaque argument produit un résultat dont le suivant a besoin.
  • Conserver les données configurables à des niveaux élevés

JAVA

  • Eviter les longues listes d’importations grâce aux caractères génériques. Si vous utilisez deux classes ou plus d’un paquetage, importez alors l’intégrité du paquetage de la manière suivante : import package.*;

Tests

  • Ne pas lésiner sur les tests, ils doivent contrôler tout ce qui peut être source de dysfonctionnement

Coder Proprement - Chapite 17.pdf