Des règles à suivre pour tout projet !

• Tous les fichiers sont encodés en utf-8 sans BOM.
• Corriger un fichier ou un bout de code qui ne respecte pas les conventions n’est jamais une perte de temps.
• Indentez proprement. Sérieusement.
• Les commentaires sont importants, mais il faut commenter intelligemment : un commentaire inutile prend de la place pour rien.
• On se décide pour une langue : on nomme toutes ses variables / classes en anglais ou en français (et, si possible, les commentaires aussi), et on s’y tient : on ne jongle pas d’une langue à l’autre.
• Les TODO sont conseillés, mais il faut les détailler : rien ne dit que c’est vous qui repasserez dessus.

La simplicité est la sophistication suprême : un code simple est plus lisible et plus facile à maintenir.

Si la même portion de code se retrouve deux fois ou plus dans un script, on en fait une fonction. Si la même portion de code se retrouve deux fois ou plus dans une classe, on en fait une méthode.

Rien ne sert de coder une méthode qui n’a pas d’implémentation ou d’utilité immédiate.

Il n’y a pas de honte à demander de l’aide, surtout avant d’attaquer une nouvelle fonctionnalité.

1. Généralités

1. Généralités
2. Bonnes pratiques
3. Performances
4. BEM
5. ITCSS
6. Préprocesseurs
7. Nomenclatures

1. Généralités
2. Bonnes pratiques
3. Performances

1. Généralités
2. Polices & typos

1. Généralités

Ces règles ont été fortement inspirées du travail de Raphaël Goetter, Pierre-Antoine Delnatte, Christophe Porteneuve, …