4 nov. 2021 14:27:35 Thomas Dumont avatar

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.

DescriptionExemple 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ésCREATE TABLE core_admin_auth_db_moduleCREATE 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éeCREATE 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ésCREATE 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éesCREATE 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 tableCREATE 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, LONGBLOBTINYBLOB
BLOB
LONGBLOB
VARBINARY
LONG VARBINARY
LONG VARBINARY
Ne pas utiliser le type TINYINTCREATE 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 SQLINSERT 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 possibleINSERT 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.