Skip to content

[FR] Dev, consignes

RemRem edited this page Apr 22, 2017 · 1 revision
  1. Si un autre contributeur a commenté du code, ne le touchez pas.

  2. Ajouter des commentaires au besoin, ne pas hésiter à être bavard dans les sources, exemple :

/**
 * dev note
 * Bout de code pour test, en cas de modification attention à l'impact sur le reste du script.
 */
  1. Si vous souhaitez supprimer du code et que vous n'avez pas le temps de tester ou que vous ne connaissez pas précisément l'impact de cette suppression, ne le supprimez pas, commentez-le ;) Vous pouvez aussi ajouter un commentaire :
// TODO Delete ?
  1. Mettez en place des fallbacks/tests, même sur des choses toutes simples, il vaut mieux un bon die( __file__ .' : '. __line__ ); qu'une erreur PHP. Si ça passe sur master, ça fera moins paniquer l'utilisateur qui n'est pas habitué ou qui stress à la vue d'une erreur PHP.
if (!mkdir( '/plante/car/pas/possibl€/')) {
    die('fail on create folder. '. __file__.' : '.__line__);
}
  1. Si vous n'avez pas le temps de tester comme il faut vos modifications/suppressions/ajouts, si c'est du POC, dites-le dans le PR ou le commit, un homme averti en vaut 10 (<- vous l'avez pigée celle-là ?).

  2. Si possible, en dev, éclatez votre code, la lecture en sera facilité, le debug aussi, par exemple : strpos('http:', explode('/',html_entities(trim($url), ENT_QUOTES, 2)['0']) > ($pi * ($earth / 360))); est plus difficile à appréhender correctement du fait qu'il n'est pas très lisible.

  3. Pour la branche dev, lorsque la roadmap est accomplie, on freeze (pas d'ajouts de fonctionnalités au core), on se limite au debug, peaufinage, nettoyage (commentaires, code...) et optimisations, histoire d'éviter de repousser sans fin la sortie d'une nouvelle version.

  4. La version est numéroté tel que : x.y.z pour major.minor.micro où :

  • major : "rupture", incompatibilité avec les versions précédentes, changement(s) majeur(s) ;
  • minor : "évolution", ajout de fonctionnalité(s), ne doit pas casser la rétro-compatibilité au sein de major ;
  • micro : "debug", essentiellement des versions de maintenance et de debug, ne doit pas casser la rétro-compatibilité au sein de minor.