Coding conventions
Formatting and presentation of Java code
To make it easier to read, the code must respect rules for setting form applied to all sources.
The main rules concerning Lutece are:
- Parentheses on a new line (Style C / C ++)
- Indentation of 4 characters
To ensure code formatting, the formatter tool must be used with the Lutece configuration file.
The general presentation of the files must respect the existing one (for Java classes the presentation of comments, code indentation, use of English ....)
The entire application must maintain homogeneity complete on both the presentation of the code and the naming rules, use of English, insertion comments ...
All source files must include the broadcast license on your mind.
HTML code: HTML standards
The HTML code produced by Lutèce and especially that of the templates must conform to the strict XHTML 1.0 Recommendation defined by the W3C (http://www.w3.org/TR/xhtml1/). The W3C accessibility recommendations should also be respected (http://www.w3.org/WAI/, HTML Techniques for WAI 1.0: http://www.w3.org TR/WCAG10-HTML-TECHS/)
Javascript
The use of javascript must be limited to the maximum because of the problems accessibility issues and user issues that disable running scripts in their browsers.
WARNING : The application must remain operational when scripts are disabled .
CSS Styles
All HTML formatting attributes must be managed by CSS2 style sheets whose specifications are defined by the W3C (http://www.w3.org/TR/REC-CSS2/).
The styles will have to use the inheritance as much as possible and the surcharges will have to be limited as much as possible.
SQL query: SQL-92 standard
All SQL queries (present in the SQL scripts or in the DAO) must follow the list of rules below in order to respect the maximum SQL-92 standard. All formats of data or syntax specific to a Database Management System (DBMS) should be avoided to ensure the possibility of use of Lutece with different DBMS.
| Description | Example of specific SQL syntax (MySQL) | Syntax SQL-92 equivalent to use |
|---|---|---|
| The anti-rib characters used for table or column names must be removed | CREATE TABLE core_admin_auth_db_module | CREATE TABLE core_admin_auth_db_module |
| The encoding definition for a column or table must be deleted | CREATE TABLE ... (access_code VARCHAR (16) collate utf8_unicode_ci, | CREATE TABLE ... (access_code VARCHAR (16), |
| When creating a table, for a column, the declaration of the default value and the fact that this column can store a NULL value must respect a given order | CREATE TABLE ... (access_code VARCHAR (16) NOT NULL DEFAULT | CREATE TABLE ... (access_code VARCHAR (16) DEFAULT '' NOT NULL |
| When creating a table, the storage engine and the encoding must not be specified | CREATE TABLE ... (...) ENGINE = MyISAM DEFAULT CHARSET = utf8 COLLATE = utf8_unicode_ci; | CREATE TABLE. .. (...); |
| The sizes of the integer fields (INT, SMALLINT, ...) must not be specified | CREATE TABLE ... (INT_nailing_list_list (11) NOT NULL DEFAULT '0', | CREATE TABLE ... (INT_keying_list) NOT NULL DEFAULT '0', |
| Delete unsigned data types. | CREATE TABLE ... (id_mailinglist INT UNSIGNEDNOT NULL DEFAULT '0', | CREATE TABLE ... (id_mailinglist INT NOT NULL DEFAULT '0', |
| Declaration of indexes explicitly and not when defining the 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); |
| Do not use the ON UPDATE CURRENT_TIMESTAMP feature to update a date field when updating a 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); |
| Do not use the data types TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Attention use LONG VARCHArrives in two words. | TINYTEXT TEXT MEDIUMTEXT LONGTEXT | VARCHAR (255) LONG VARCHAR LONG VARCHAR LONG VARCHAR |
| Do not use the data types TINYBLOB, BLOB, LONGBLOB | TINYBLOB BLOB LONGBLOB | VARBINARY LONG VARBINARY LONG VARBINARY |
| Do not use the type TINYINT | CREATE TABLE ... (status TINYINT); | CREATE TABLE ... (status SMALLINT); |
| Removed MySQL comments generated when exporting a table for example. | / *! 40101 SET NAMES utf8 * /; | |
| Do not make multiple insertions in a single SQL statement | INSERT INTO core_admin_right VALUES (...), (...), (...), (...); | INSERT INTO core_admin_right VALUES (...); INSERT INTO core_admin_right VALUES (...); INSERT INTO core_admin_right VALUES (...); INSERT INTO core_admin_right VALUES (...); |
| Do not use the backslash escape character. To escape a single odds, you have to double each simple rating. Do not use a quoted boundary to delimit a field, use a single dimension. Access to resources INSERT INTO core_admin_right VALUES (contents) Carriage return \ r \ nNew line | Access to resourcesINSERT INTO core_admin_right VALUES ('content' ) Carriage returnbr / New line | |
| To reduce the risk of incompatibility always prefer to store data in binary where possible | INSERT INTO core_stylesheet (...) VALUES ('xsl: stylesheet version = 1.0 ...') | INSERT INTO core_stylesheet (... ) VALUES (0x3C3F786D6C207665) |
Comments
All elements of the application (programs, scripts, properties files, ...) should be commented. Comments should be written in English.
For Java programs, all classes and their methods (including protected and private) will have to include Javadoc comments containing a description of the functionality supported by the method, as well as the tags @ param @return @ exception .
Changes made in successive versions will be indicated by @ version tags.
The new API methods and classes will indicate their version introduction using the @ since tag.
Obsolete methods will be identified using the @ deprecated tag.
Compliance with accessibility standards
In the context of Article 47 of Law No 2005-102 of 12 February 2005, local authorities must make their websites accessible to every citizen regardless of their hardware or software, their network infrastructure, their mother tongue, their culture, their geographical location, or their physical or mental abilities.
Article 47 of Law No. 2005-102
The public online communication services of State services, local authorities and the public institutions that depend on it must be accessible to people disabled .
The accessibility of communication services Public Online is about access to any type information in digital form whatever the means of access, the contents and the mode of consultation. International recommendations for the accessibility of the internet must be applied for communication services public.
The rules described in Annex 6.4 recall the list of accessibility rules established by the Agency for the Development of the Electronic Administration (ADAE)
The Holder undertakes to respect, for all its deliverables, the rules described in the Accessibility Repository for Internet Services of the French administration established by the Agency for the Development of the Electronic Administration (ADAE became DGME).
In this context, the Holder undertakes to make the necessary corrections on the services performed under the contract following a labeling operation or certification based on the criteria specified in this standard.