Skip to content

Guidelines

Guidelines pour les projets web Bleu122

CSS + JS

  • Eviter les appels externes tant que possible (importer les fichiers des librairies).

CSS

  • Interdiction de copier / coller le chemin CSS vers l’élément (exemple : html body div#wrapper nav.navbar.navbar-default.navbar-static-top div.navbar-default.sidebar)
  • Ne pas importer plusieurs librairies concurrentes (bootstrap + materialize par exemple). Ou alors importer la partie spécifique de l’un si nécessaire (seulement les inputs par exemple).
  • Créer des variables pour les couleurs
  • Convention de nommage : nom définissant
  • Eviter le inline (styles= directement dans le HTML (toujours séparer le CSS dans un fichier à part))
  • (Découper les CSS en fichiers selon les pages) >> Ajouter commentaire pour code spécifique à une page
  • Pas de fichier CSS de plus de 2000 lignes
  • Les espacements (margin, padding) sont des multiples de 4px (cf material design)
  • Pas de camelCase >>> utilisation des tirets -

  • Ne pas surcharger les classes natives des frameworks (.container par exemple) mais créer classe spécifique (.container-custom par exemple).

  • Responsive : Utilisation de max-width only.
    /* Extra large devices (large desktops, 1200px and down) */
    @media (max-width: 1200px) { ... }
    /* Large devices (desktops, 992px and down)*/
    @media (max-width: 992px) { ... }
    /* Medium devices (tablets, 768px and down) */
    @media (max-width: 768px) { ... }
    /* Small devices (landscape phones, 576px and down) */
    @media (max-width: 576px) { ... }
    /* Small devices (landscape phones, 320px and down) */
    @media (max-width: 320px) { ... }

JS

  • Pas de JS dans le HTML > tout dans des fichiers séparés : un fichier custom.js et un fichier par page s’il y a de la logique dessus

  • Design pattern objet (cf projets récents)

  • Listeners, pas onClick =

  • Importer les fichiers JS dans le header pour les applications pro

  • CamelCase

Objets de domaine Grails

  • On précise dans les constraints si la propriété est nullable. Sinon, par défaut, elle ne l’est pas.

  • Si une string est nullable, préciser qu’elle ne peut pas être blank (city nullable: true, blank: false).

  • Penser à préciser la contrainte d’unicité de la table (une seule région par pays avec le même nom par exemple).

  • Penser à gérer les 2 côtés de la relation (ne pas oublier les hasMany).

  • Type des propriétés en majuscules : Long, String… (pas long, string)

Sécurité

  • Voir le fichier guidelines-security.md

Npm

  • Pendant le dev, on ne commit/push pas les dépendances. Par contre avant la mise en prod, on commit et on push tout, y compris les dépendances (node_modules etc) pour être sûr d’avoir un projet opérationnel au prochain pull.