Les normes des programmeurs généraux sont essentiellement dictées par deux organismes :
Nom | Normes |
---|---|
ISO | Les normes Internationale adopté par plus de 146 pays à travers le monde |
ANSI | Les normes américaine étant l'ancienne référence |
En plus de ces deux normes, il y a plein de normes spécifique à chacun des langages de programmation. Enfin, il y a les normes informels, appliqué par les programmeurs d'expériences :
But | Description |
---|---|
Base de données | Toujours spécifié le nom de chacun des champs dans une requête SQL plutôt qu'un «*». Par exemple lorsqu'on effectue de la maintenance sur une table et qu'on ajoute un nouveau champs ou au contraire qu'on supprime un champs, le code devient incompatible et boguer à cause que les champs ne corresponde plus. |
Comprendre | Mettre des remarques et documenté. |
Éviter de coder en dur | Lorsqu'on utilise des identificateurs dans une base de données, on utilise un ID pour les chiffres, et un MID pour les lettres. Par exemple un code de langue 'FR' sera un MID, tandis qu'un 1 sera un ID. |
Éviter la corruption de données | Ne pas effectuer des insertions directement SQL dans la base de données lorsqu'il existe une composante offrant se genre de servir |
Ne pas sauvegarder ses requêtes dans un fichier document comme Word ou autre car ils effectuent des interprétations automatique de données. | |
Incompatibilité | Éviter d'effectuer des mélanges technologiques inutile. Du ASP, PHP, JSP et Perl ne devrait pas se retrouver dans un même site. |
Impossible à maintenir à jour | Utilisé le même gabarie pour n'importe quel langue fournir par un site Web. Ne surtout pas développer un site en français dans un répertoire «/fr», un site anglais dans un site «/en», sinon on risque de favoriser et négliger l'autre, en plus le compte de développement est toujours multiplié par deux. |
Mauvais noms | Toujours copier-coller une nom de procédure, fonction ou variable. Lorsqu'on réécrit à chaque fois le nom, il y a toujours un risque qu'il y a une lettre de trop ou manquante, minuscule plutôt que majuscule et ainsi créer un bug étrange par effet de ricochet. |
Nom inconnu | Toujours prendre un nom de variable significatif. Password pour mot de passe, et non pas A pour votre première variable, B pour votre deuxième variable,... |
Portabilité | Les noms de fichiers toujours en majuscule ou toujours en minuscule. Cause des ennuis, lorsqu'on passe de Windows à Unix. |
Sécurité utilisateur | Ne jamais écrit une mot de passe en claire dans la base de données, utilisé un encodage quelconque (MD5, SHA-1,...). |
Système instable | Éviter les dépendances envers l'extérieur, il faut bâtir une application reposant essentiellement sur elle-même. De ce fait, maximiser la cohésion et minimiser le couplage. |
Voir également
Article - Revue de code (code review)
Dernière mise à jour : Dimanche, le 1 mai 2016