Règles de codage
Mise en forme et présentation du code Java
Pour faciliter sa lecture, le code doit respecter des règles de mise en forme appliquées à l'ensemble des sources.
Les principales règles concernant Lutèce sont :
- Parenthèses sur une nouvelle ligne (Style C/C++)
- Indentation de 4 caractères
Afin de garantir le formatage du code, l’outil Formatter doit être utilisé avec le fichier de configuration de Lutèce.
La présentation générale des fichiers devra respecter celle existante (pour les classes java la présentation des commentaires, indentation du code, utilisation de l’anglais….)
L’ensemble de l’application doit conserver une homogénéité complète tant sur la présentation du code que sur les règles de nommages, l’utilisation de l’anglais, l’insertion de commentaires….
Tous les fichiers sources doivent comporter la licence de diffusion en entête.
Code HTML : les normes HTML
Le code HTML produit par Lutèce et notamment celui des templates doit être conforme à la recommandation XHTML 1.0 stricte définie par le W3C (http://www.w3.org/TR/xhtml1/). Les recommandations du W3C concernant l'accessibilité doivent également être respectées (http://www.w3.org/WAI/, HTML Techniques for WAI 1.0: http://www.w3.org/TR/WCAG10-HTML-TECHS/)
Le Javascript
L'usage du javascript doit être limité au maximum en raison des problèmes d'accessibilité engendrés et des problèmes liés aux utilisateurs qui désactivent l'exécution des scripts dans leurs navigateurs.
ATTENTION : L'application doit impérativement rester opérationnelle lorsque les scripts sont désactivés. ===Les Styles CSS===
Tous les attributs de mise en forme du code HTML doivent être gérés par des feuilles de style CSS2 dont les spécifications sont définies par le W3C (http://www.w3.org/TR/REC-CSS2/).
Les styles devront utiliser au maximum l'héritage et les surcharges devront être limitées au maximum.
Requête SQL : norme SQL-92
Toutes les requêtes SQL (présentes dans les scripts SQL ou dans les DAO) doivent suivres la liste de règles ci-dessous afin de respecter au maximum la norme SQL-92. Tous les formats de données ou syntaxes spécifiques à un Système de Gestion de Base de Données (SGBD) doit être évité afin de garantir la possibilité d'utilisation de Lutèce avec différents SGBD.
Description | Exemple de syntaxe SQL spécifique (MySQL) | Syntaxe SQL-92 équivalente à utiliser |
---|---|---|
Les caractères anti-côtes utilisés pour les noms de tables ou de colonnes doivent être supprimés | CREATE TABLE core_admin_auth_db_module | CREATE TABLE core_admin_auth_db_module |
La définition de l'encodage pour une colone ou une table doit être supprimé | CREATE TABLE ... (access_code VARCHAR(16) collate utf8_unicode_ci, | CREATE TABLE ... (access_code VARCHAR(16), |
Lors de la création d'une table, pour une colonne, la déclaration de la valeur par défaut et le fait que cette colonne puisse stocker une valeur NULLdoit être respecter un ordre donnée | CREATE TABLE ... (access_code VARCHAR(16) NOT NULL DEFAULT | CREATE TABLE ... (access_code VARCHAR(16) DEFAULT '' NOT NULL |
Lors de la création d'une table, le moteur de stockage ainsi que l'encodage ne doivent pas être spécifiés | CREATE TABLE ... ( ... ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; | CREATE TABLE ... ( ... ) ; |
Les tailles des champs de type entier (INT, SMALLINT, ...) ne doivent pas être spécifiées | CREATE TABLE ... (id_mailinglist INT(11)NOT NULL DEFAULT '0', | CREATE TABLE ... (id_mailinglist INT NOT NULL DEFAULT '0', |
Suppression des types de données non signées. | CREATE TABLE ... (id_mailinglist INT UNSIGNEDNOT NULL DEFAULT '0', | CREATE TABLE ... (id_mailinglist INT NOT NULL DEFAULT '0', |
Déclaration des index de manière explicite et non lors de la définition de la table | CREATE TABLE core_admin_right ( ... , KEY index_right (level_right, admin_url)) | CREATE TABLE core_admin_right ( ... );CREATE INDEX index_right ON core_admin_right (level_right, admin_url); |
Ne pas utiliser la fonctionnalité ON UPDATE CURRENT_TIMESTAMPpermettant de mettre à jour un champ date lors de la mise à jour d'un tuple. | CREATE TABLE ... ( date_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL ON UPDATE CURRENT_TIMESTAMP); | CREATE TABLE ... ( date_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL); |
Ne pas utiliser le types de données TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Attention utiliser LONG VARCHARécrit en deux mots. | TINYTEXT TEXTMEDIUM TEXT LONGTEXT | VARCHAR(255) LONG VARCHAR LONG VARCHAR LONG VARCHAR |
Ne pas utiliser le types de données TINYBLOB, BLOB, LONGBLOB | TINYBLOB BLOB LONGBLOB | VARBINARY LONG VARBINARY LONG VARBINARY |
Ne pas utiliser le type TINYINT | CREATE TABLE ... ( status TINYINT); | CREATE TABLE ... ( status SMALLINT); |
Suppression des commentaires MySQL générés lors de l'export d'une table par exemple. | /*!40101 SET NAMES utf8 */; | |
Ne pas faire d'insertions multiples en une seule requête SQL | INSERT INTO core_admin_right VALUES (...),(...),(...),(...); | INSERT INTO core_admin_right VALUES (...); INSERT INTO core_admin_right VALUES (...); INSERT INTO core_admin_right VALUES (...); |
Ne pas utiliser le caractère d'échappement antislash. Pour échapper une simple cote, il faut doubler chaque simple cote. Ne pas utiliser de double cote pour délimiter un champ, utiliser une simple cote. | L 'accès aux ressourcesINSERT INTO core_admin_right VALUES (contenu)Retour chariot\r\nNouvelle ligne | L''accès aux ressourcesINSERT INTO core_admin_right VALUES ('contenu')Retour chariotbr /Nouvelle ligne |
Pour limiter les risques d'incompatibilité toujours préférer stocker les données en binaire lorsque cela est possible | INSERT INTO core_stylesheet (... ) VALUES ( 'xsl:stylesheet version=1.0...' ) | INSERT INTO core_stylesheet (... ) VALUES ( 0x3C3F786D6C207665) |
Commentaires
L’ensemble des éléments de l’application (programmes, scripts, fichiers de propriétés, …) devra être commenté. Les commentaires devront être rédigés en anglais.
Pour les programmes Java, l’ensemble des classes et de leurs méthodes (y compris protected et private) devra comporter des commentaires Javadoc contenant une description de la fonctionnalité prise en charge par la méthode, ainsi que les tags @param @return @exception .
Les modifications réalisées dans les versions successives seront indiquées par des tags @version .
Les nouvelles méthodes et classes des API indiqueront leur version d'introduction à l'aide de la balise @since .
Les methodes obsolètes seront identifiées à l'aide de la balise @deprecated .
Respect des normes d’accessibilité
Dans le cadre de l'article 47 de la loi n°2005-102 du 12 février 2005, les collectivités territoriales doivent rendre accessibles leurs sites web à chaque citoyen quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.
Article 47 de la loi n° 2005-102
Les services de communication publique en ligne des services de l'Etat, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées.
L'accessibilité des services de communication publique en ligne concerne l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation. Les recommandations internationales pour l'accessibilité de l'internet doivent être appliquées pour les services de communication publique en ligne.
Les règles décrites à l’annexe 6.4 rappellent la liste des règles relatives à l’accessibilité établies par l’Agence pour le Développement de l’Administration Electronique (ADAE)
Le Titulaire s'engage à respecter, pour l'ensemble de ses livrables, les règles décrites dans le référentiel accessibilité des services Internet de l'administration française établi par l'Agence pour le Développement de l'Administration Electronique (ADAE devenue DGME).
Dans ce cadre, le Titulaire s'engage à opérer les corrections nécessaires sur les prestations réalisées dans le cadre du marché suite à une opération de labellisation ou de certification basée sur les critères spécifiés dans ce référentiel.