1. LES RÈGLES DE DÉVELOPPEMENT
ANGULAR
version 1.0
Ben Khalfallah Héla
2. NOMENCLATURE
les noms des fichiers html : kebab-case ou all-lower-case-
dash.
Exemples : user-comment-list, community-item, user-my-
wishlist.
https://github.com/rangle/angular2-guidelines
2
3. NOMENCLATURE
les noms des variables css : kebab-case ou all-lower-case-dash.
Examples : category-header-title, toolbar-title, myspace-item-icon, myspace-item-title.
➤ Le css adopte cette règle : tous les attributs et les valeurs css sont de la forme :
margin-left, margin-top, background-color, inline-block, …
https://github.com/rangle/angular2-guidelines
3
http://getbem.com/introduction/
https://www.w3.org/TR/css3-selectors/#sequence
4. NOMENCLATURE
les noms des classes Typescript : UpperCamelCase (la
première lettre du mot en majuscule).
pour avoir le nom des fichiers Typescript en UpperCamelCase,
il faut séparé les mots par “-“ lors de la génération :
ng g component user-wish-list => UserWishList
https://github.com/rangle/angular2-guidelines
4
UpperCamelCase : ApplicationAddReviewComponent
5. NOMENCLATURE
les noms des attributs dans une classe ou model :
lowerCamelCase :
le premier mot du nom est en minuscule.
les autres mots du nom commencent par une majuscule.
https://github.com/rangle/angular2-guidelines
5
lowerCamelCase : categoryIcon
7. NOMENCLATURE
les noms des méthodes ou fonctions: lowerCamelCase.
https://github.com/rangle/angular2-guidelines
7
8. TEST DU RESPONSIVE
8
Outils de vérification du responsive
http://quirktools.com/screenfly/#u=http%3A//localhost%3A4200/&w=360&h=640&a=39
http://ami.responsivedesign.is/#
http://www.isresponsive.com/Tester?site=http://localhost:4200/
Breakpoints cibles :
Nous devons avoir deux versions pour ne pas alourdir le code avec des if et
des cas particuliers :
- une version pour les desktops, les iPads & les tablettes.
- une version mobile.
9. RÈGLES GÉNÉRALES
Typescript est une language orienté objet.
Les noms des classes, variables et attributs doivent être
significatifs: le nom suffit pour connaitre le rôle et
l’emplacement.
Il faut mettre des commentaires dans le code typescript avant chaque
méthode, dans le code html et dans le code css.
Les commentaires sont très importants pour expliquer ce que fait
une fonction sans avoir besoin de comprendre le code.
Les urls sont déclarés comme constantes (statiques) une et une seule
fois (mise à jour simple).
➤ Chaque string utilisée dans le html, doit obligatoirement passée par
“translate” même si elle a la même valeur dans toutes les languages
pour éviter le retard perdu dans les retours de vérifications.
9
10. RÈGLES GÉNÉRALES
➤ Chaque composant html doit avoir son propre mise en forme css pour :
éviter les cas comme changer la mise en forme d’un élément entraine le changement non voulue d’un
autre.
automatiser la mise en forme.
séparation entre développement et mise en forme : si nous donnons le ficher css à un intégrateur web
ou designer il peut modifier la mise en forme sans risquer l’application et les parties déjà stabilisées.
10
11. RÈGLES GÉNÉRALES
➤ Privilégier le module au component si le module est réutilisable par
d’autres applications : automatisation via npm.
➤ Le Typescript est un language orienté objet : veuillez respecter les
règles principales d’orienté objet :
Séparation du contexte : séparation des couches : UI séparé des
services et des providers.
Single responsability principle: une classe doit effectuée un seul rôle.
Par exemple une classe rest-services qui effectue le chargement des
famous, recipes et drinks doit être décomposée en 3 classes.
Open Closed Principle : “you should be able to extend the behavior
of your a system without having to modify it”. Nous devons écrire un
code qui ne doit pas être changé chaque fois que les conditions
changent (fichier constante, settings séparé du code).
11