meta données pour cette page
RÉFÉRENTIEL : Conventions de Nommage Angular
Ce document définit les standards de nommage à respecter sur l'ensemble de nos projets Angular afin de garantir la cohérence du code, faciliter la maintenance et améliorer la lisibilité pour toute l'équipe.
1. Structure des Fichiers (kebab-case)
La règle d'or est le “Pattern à deux points” : nom.type.extension.
Tous les noms de fichiers doivent être en kebab-case (minuscules et tirets).
| Type de fichier | Convention | Exemple |
|---|---|---|
| Composant | nom.component.ts | user-profile.component.ts |
| Service | nom.service.ts | auth.service.ts |
| Module | nom.module.ts | app-routing.module.ts |
| Interface / Modèle | nom.model.ts | hero.model.ts |
| Guard | nom.guard.ts | auth.guard.ts |
| Pipe | nom.pipe.ts | file-size.pipe.ts |
| Directive | nom.directive.ts | highlight.directive.ts |
| Store / Facade | nom.store.ts | user.store.ts |
2. Classes et Types (PascalCase)
Les noms de classes utilisent le PascalCase et doivent inclure le suffixe correspondant à leur rôle.
- Composants :
export class UserProfileComponent { }
- Services :
export class AuthService { }
- Pipes :
export class FileSizePipe { }
- Directives :
export class HighlightDirective { }
- Guards :
export class AuthGuard { }
- Stores / Facades :
export class UserStore { }
3. Sélecteurs de composants et directives
Les sélecteurs doivent :
- utiliser kebab-case
- avoir un préfixe spécifique au projet
Exemple :
<app-user-list></app-user-list><app-dashboard></app-dashboard>
Incorrect :
<user-list></user-list>
Le préfixe par défaut Angular est app-, mais il peut être remplacé par un préfixe métier (ex : logeas-).
Exemple :
<logeas-grid></logeas-grid>
4. Tests Unitaires (.spec.ts)
Les fichiers de tests portent le même nom que le fichier testé.
Exemple :
auth.service.tsauth.service.spec.ts
Structure recommandée :
describe('AuthService', () => {
it('should return true when user is authenticated', () => {
});
});
Bonnes pratiques :
- décrire le comportement attendu
- utiliser la forme should …
5. Assets et Ressources Statiques
Tous les fichiers statiques utilisent kebab-case.
Exemples :
logo-entreprise.svguser-avatar-placeholder.png
Organisation recommandée :
assets/images/assets/icons/assets/i18n/assets/config/
6. Logique Interne (camelCase)
Les variables et méthodes utilisent le camelCase.
Exemples :
- variables
isValid: boolean = false
- méthodes
updateUserData()
- inputs
@Input() userRole: string
- outputs
@Output() userChanged = new EventEmitter<User>()
7. Observables
Les Observables doivent être suffixés par `$`.
Exemples :
users$ : Observable<User[]>; isLoading$ : Observable<boolean>; currentUser$ : Observable<User>;
Exemple dans un template :
<div *ngIf="users$ | async as users">
8. Constantes et Énumérations
Constantes globales :
UPPER_SNAKE_CASE
export const MAX_FILE_SIZE = 5000;
Enums :
- nom en PascalCase
- valeurs en PascalCase ou UPPER_SNAKE_CASE
export enum UserRole {
Admin,
Member,
Guest
}
9. Organisation des dossiers
Structure recommandée :
src/app/ core/ services globaux guards interceptors shared/ composants réutilisables pipes directives features/ modules métier features/user/ user.component.ts user.service.ts user.store.ts user.model.ts
Principes :
- core → singleton global
- shared → réutilisable
- features → logique métier
10. Recommandations additionnelles
Interfaces :
- ne pas utiliser le préfixe “I”
Correct :
User Account Invoice
Incorrect :
IUser IAccount
Services :
Nommer selon la responsabilité métier
Correct :
AuthService StorageService NotificationService
Incorrect :
DataService HelperService UtilsService
11. Bonnes pratiques générales
- un fichier = une classe principale
- éviter les fichiers trop longs (>500 lignes)
- privilégier les composants petits et spécialisés
- éviter la logique métier dans les composants → préférer les services ou stores