# Directives pour la programmation

Tout projet où l'on travaille en collaboration nécessite une cohérence et une stabilité fortes.

L'objectif de ces directives est de fournir un cadre à respecter pour tout le code de Moodle. Il est vrai que certaines parties plus anciennes du code ne les respectent pas toujours ; le code sera corrigé. Tout le nouveau code doit absolument respecter ces directives aussi précisément que possible.

## Règles générales

1. Tous les fichiers contenant du code doivent avoir l'extension .php.
2. Tous les fichiers modèles (« themes ») doivent avoir l'extension .html.
3. Tous les fichiers en format texte doivent être en format Unix (la plupart des éditeurs de texte permettent de convertir les caractères de fin de ligne).
4. Toutes les balises php doivent être en forme complète, comme ceci , et non en forme abrégée comme ceci .
5. Toutes les indications de copyright doivent être conservées. Vous pouvez ajouter les vôtres au besoin.
6. Tous les fichiers doivent comporter une commande d'inclusion du fichier config.php principal.
7. Tous les fichiers doivent vérifier que l'utilisateur est correctement authentifié, à l'aide de require_login() et d'une des fonctions isadmin(), isteacher(), iscreator() et isstudent().
8. Tous les accès aux bases de données doivent autant que possible utiliser les fonctions définies dans lib/datalib.php. Ceci permet la compatibilité avec un grand nombre de marques de bases de données. Il est possible de faire presque tout avec ces fonctions. Si vous devez écrire du code SQL, assurez-vous qu'il soit : multi-plateforme, restreint à des fonctions spécifiques de votre code (habituellement placés dans un fichier lib.php) et clairement marqué.
9. Ne créez et n'utilisez aucune variable globale, sauf les variables standard $CFG, $SESSION, $THEME et $USER.
10. Toutes les variables doivent être initialisées ou au moins leur existence doit être testée avec isset() ou empty() avant leur utilisation.
11. Toutes les chaînes de caractères doivent être traduisibles. Créez les nouvelles chaînes dans les fichiers du dossier « lang/en », donnez-leur des noms en minuscules, courts, en anglais, et utilisez-les dans votre code par l'intermédiaire des fonctions get_string() ou print_string().
12. Tous les fichiers d'aide doivent être traduisibles. Créez-les dans le dossier « lang/en/help » et appelez-les avec la fonction helpbutton().
13. Les magic_quotes sont automatiquement appliquées aux données en provenance du navigateur (envoyées via GET ou POST), indépendamment des réglages de PHP. Il est donc sûr de les insérer directement dans la base de données. Toutes les autres données brutes (en provenance de fichiers ou de bases de données) doivent être encodées avec addslashes() avant de les insérer dans la base de données.
14. IMPORTANT : tous les textes dans Moodle, tout particulièrement ceux qui proviennent des utilisateurs, doivent être affichés à l'aide de la fonction format_text(). Ceci permet de s'assurer que le texte est filtré et nettoyé correctement.

## Style du code

Je suis conscient qu'il est ennuyeux de changer votre style si vous avez d'autres habitudes, mais comparez cet embêtement avec les gros ennuis qu'ont ultérieurement les personnes qui essaient de comprendre un code composé dans des styles différents. Bien sûr il y a des avantages et des inconvénients à chaque style, mais le style de Moodle existe, alors tenez-vous y, s'il vous plaît.

1. L'indentation doit être de 4 espaces. N'utiliser pas DU TOUT de tabulations.
2. Les noms des variables doivent toujours être des mots anglais en minuscules, faciles à lire et ayant une signification claire. Si vous avez vraiment besoin de plusieurs mots, concaténez-les, mais gardez-les aussi courts que possible. Utilisez des noms au pluriel pour les tableaux d'objets.

   BON : $quiz
   BON : $errorstring
   BON : $assignments (pour un tableau d'objets)
   BON : $i (mais seulement dans de petites boucles)
   MAUVAIS : $Quiz
   MAUVAIS : $aReallyLongVariableNameWithoutAGoodReason
   MAUVAIS : $error_string

3. Les noms des constantes doivent toujours être en majuscules, et toujours commencer par le nom du module. Les mots qui les constituent doivent être séparés par des caractères « souligné » (underscore).

   define("FORUM_MODE_FLATOLDEST", 1);

4. Les noms des fonctions doivent être de simples mots anglais en minuscules, et commencer par le nom du module, pour éviter les conflits entre modules. Les mots qui les constituent doivent être séparés par des caractères « souligné » (underscore). Les paramètres doivent avoir si possible une valeur par défaut sensée. On ne place pas d'espace entre le nom de la fonction et la suite (parenthèses)

   function forum_set_display_mode($mode=0) {
   global $USER, $CFG;
   if ($mode) {
   $USER->mode = $mode;
   } else if (empty($USER->mode)) {
   $USER->mode = $CFG->forum_displaymode;
   }
   }

5. Les blocs doivent toujours être placés entre accolades (même s'ils ne sont constitués que d'une ligne). Moodle utilise le style suivant :

   if ($quiz->attempts) {
   if ($numattempts > $quiz->attempts) {
   error($strtoomanyattempts, "view.php?id=$cm->id");
   }
   }

6. Les chaînes de caractères doivent être définies avec des apostrophes droites (pas des guillemets) lorsque c'est possible, afin d'améliorer les performances.

   $var = 'some text without any variables';
   $var = "with special characters like a new line \n";
   $var = 'a very, very long string with a '.$single.' variable in it';
   $var = "some $text with $many variables $within it";

7. Les commentaires doivent être ajoutés autant que possible, dans le but d'expliciter le fonctionnement du code et le pourquoi des fonctions et variables.
   - Toutes les fonctions (et les classes) doivent utiliser le format très répandu phpDoc, qui permet la génération automatique de la documentation du code.
   - Dans le code lui-même, il convient d'utiliser le style //, formatté proprement, de sorte que les commentaires soient bien ajustés et alignés avec le code.

   /**
   * La description doit apparaître d'abord, avec des astérisques positionnés
   * exactement comme dans cet exemple. Pour vous référer à une autre fonction,
   * utiliser cette syntaxe : {@link clean_param()}. Après la description de la
   * fonction, ajouter celle de chacun des paramètre de la façon suivante.
   *
   * @param int $postid Le type PHP est suivi du nom de la variable
   * @param array $scale Le type PHP est suivi du nom de la variable
   * @param array $ratings Le type PHP est suivi du nom de la variable
   * @return mixed
   */
   function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {
   if (!$ratings) {
   $ratings = array(); // Initialize the empty array
   if ($rates = get_records("forum_ratings", "post", $postid)) {
   // Process each rating in turn
   foreach ($rates as $rate) {
   ... etc.

8. Les espaces doivent être utilisés généreusement. N'ayez pas peur d'espacer les lignes pour accroître la lisibilité. En général, il doit y avoir un espace entre les parenthèses et les instructions normales, mais aucun espace entre les parenthèses et les variables ou fonctions :

   foreach ($objects as $key => $thing) {
   process($thing);
   }
   if ($x == $y) {
   $a = $b;
   } else if ($x == $z) {
   $a = $c;
   } else {
   $a = $d;
   }

## Structure des bases de données

1. Toutes les tables doivent avoir un champ id (INT10) à incrémentation automatique pour index principal.
2. La table principale contenant les instances de chaque module doit avoir le même nom que le module (par exemple bidule) et doit contenir au moins les champs suivants :
   - id : voir description ci-dessus
   - course : l'identifiant du cours auquel appartient chaque instance
   - name : le nom complet de chaque instance du module
3. Les autres tables associées à un module et contenant des informations sur des « machins » doivent être appelées bidule_machins (remarquez le pluriel).
4. Les noms de colonnes doivent être simples et courts, suivant les mêmes règles que les noms des variables.
5. Si possible, les colonnes faisant référence au champ id d'une autre table (par exemple bidule) doivent être appelées biduleid. Cette convention est nouvelle, et n'a pas été suivie dans certaines tables plus anciennes.
6. Les champs booléens doivent être implémentés comme des entiers petits (par exemple INT4) contenant 0 ou 1, afin de permettre une éventuelle extension des valeurs si nécessaire.
7. La plupart des tables doivent avoir un champ timemodified (INT10) qui soit mis à jour avec la date et l'heure obtenue avec la fonction PHP time().

## Problèmes de sécurité (et traitement des données des formulaires et des URLs)

1. Ne vous basez pas sur l'option « register_globals ». Toutes les variables doivent être correctement initialisées dans tous les fichiers de code. La provenance du nom de la variable doit être évidente.
2. Initialisez tous les tableaux et tous les objets, même lorsqu'ils sont vides. `$a = array()` ou `$obj = new stdClass();`.
3. N'utilisez pas la fonction `optional_variable()`. Utilisez en lieu et place la fonction `optional_param()`. Choisissez la valeur PARAM_XXXX correcte pour le type de données que vous attendez. Pour vérifier et assigner une valeur optionnelle à une variable, utilisez la fonction `set_default()`.
4. N'utilisez pas la fonction `require_variable()`. Utilisez en lieu et place la fonction `required_param()`. Choisissez la valeur PARAM_XXXX correcte pour le type de données que vous attendez.
5. N'utilisez la fonction `data_submitted()` qu'avec précaution. Avant son utilisation, n'oubliez pas de nettoyer les données.
6. N'utilisez pas `$_GET`, `$_POST` ni `$_REQUEST`. Utilisez la fonction `required_param()` ou `optional_param()` appropriée à vos besoins.
7. Ne vérifiez pas l'exécution d'actions avec par exemple `if (isset($_GET['something']))`. Utilisez plutôt `$something = optional_param( 'something',-1,PARAM_INT )` et effectuez ensuite un test correct pour vérifier si la valeur se trouve dans l'intervalle voulu, par exemple `if ($something>=0) {...`.
8. Groupez chaque fois que cela est possible vos `required_param()`, `optional_param()` et les autres initialisations de variables initialisation au début de chaque fichier, de sorte qu'elles soient faciles à trouver.
9. Utilisez le mécanisme « sesskey » pour protéger vos routines de traitement de formulaires d'éventuelles attaques. Un exemple simple : lorsque le formulaire est généré, ajoutez ``. Lors du traitement du formulaire, vérifiez avec `if (!confirm_sesskey()) {error('Bad Session Key');}`.
10. Tous les noms de fichiers doivent être nettoyés par la fonction `clean_filename()`, pour autant que cela n'ait pas encore été fait par une utilisation adéquate de `required_param()` ou de `optional_param()`.
11. Toutes les données lues dans la base de données doivent être passées par `addslashes()` avant d'être récrites dans la base de données. La fonction `addslashes_object()` permet de traiter ainsi un objet complet de données.
12. Chaque fois que c'est possible, les données devant être stockées dans la base de données doivent provenir de données `POST` (d'un formulaire avec `method="POST"`), et non de données `GET` (c'est-à-dire provenant de l'URL).
13. Si vous pouvez l'éviter, n'utilisez pas de données provenant de la variable `$_SERVER`, en raison de problèmes de portabilité.
14. Si cela n'a pas été fait ailleurs, assurez-vous que toutes les données écrites dans la base de données ont été traitées par la fonction `clean_param()` avec le paramètre PARAM_XXXX adéquat au type de données.
15. Si vous écrivez du code SQL brut, assurez-vous très attentivement qu'il est correct. Faites tout particulièrement attention aux guillemets manquants autour des valeurs, pouvant se transformer en autant de failles de sécurité (injections SQL).
16. Vérifiez toutes les données (particulièrement celles qui sont écrites dans la base de données) dans tous les fichiers où elles sont utilisées. N'attendez rien et ne vous reposez sur rien de ce qui est fait ailleurs.
17. Les blocs de code à inclure doivent comporter une structure PHP définie (par exemple, une déclaration de classe, des définitions de fonctions, etc.), Les blocs de code non structurés engendrent l'utilisation de variables non initialisées.

Documentation Moodle

Version: $Id: coding.html,v 1.9.2.3 2006/02/06 09:59:43 moodler Exp $