Revue de Code en TypeScript : Ce qu'il Faut Vérifier et Comment Donner un Retour d'Expérience Concret
\n\nLa revue de code n'est pas qu'une simple formalité, mais un outil puissant pour améliorer la qualité du code. En TypeScript, avec son système de typage riche, la revue peut être particulièrement efficace. Dans cet article, nous détaillerons à quoi faire attention lors de la revue de code TypeScript, et comment donner un retour d'expérience utile plutôt que blessant. Tous les exemples sont basés sur du code réel.
\n\n1. Types et Annotations : Évitez `any` et Utilisez la Rigueur
\n\nLa première chose qui saute aux yeux dans une revue de code TypeScript, ce sont les types. TypeScript est conçu pour détecter les erreurs à la compilation, donc any est un signal d'alarme.
Ce qu'il Faut Vérifier :
\n- \n
- Présence de
any. Chaqueanydoit être justifié. S'il s'agit d'une migration depuis JS, c'est acceptable, mais dans du nouveau code, ça ne l'est pas. \n - Exactitude des types. N'utilisez pas
stringlà où unenumou untype unionest nécessaire. \n - Typage excessif. TypeScript peut inférer les types. N'écrivez pas
const x: number = 5— écrivezconst x = 5. \n - Paramètres stricts. Vérifiez que
tsconfig.jsoncontientstrict: true,noImplicitAny,strictNullChecksactivés. \n
Exemple de Mauvais Code :
\nfunction processData(data: any) {\n return data.name.toLowerCase();\n}\n\nComment le Corriger :
\ninterface User {\n name: string;\n}\n\nfunction processData(data: User): string {\n return data.name.toLowerCase();\n}\n\nComment Donner un Retour :
\nAu lieu de « Tu utilises any, c'est mal », dites : « Ici any désactive la vérification de type. Décrivons l'interface User — cela améliorera la sécurité et la lisibilité du code. »
2. Gestion de null et undefined : strictNullChecks Sauve des Vies
\n\nLes erreurs Cannot read property of undefined sont classiques. TypeScript avec strictNullChecks aide à les éviter, mais seulement si le développeur gère correctement les valeurs nullable.
Ce qu'il Faut Vérifier :
\n- \n
- Vérification de null/undefined avant d'accéder aux propriétés. \n
- Utilisation du chaînage optionnel (
?.) — c'est moderne et sûr. \n - L'opérateur
!(assertion non-null) — à utiliser uniquement si vous êtes sûr à 100% que la valeur n'est pas nulle. Mieux vaut le remplacer par une vérification explicite. \n - Utilisation correcte de
??(coalescence nulle) au lieu de||pour les valeurs par défaut. \n
Exemple de Mauvais Code :
\nfunction getCity(user: User | null): string {\n return user!.address!.city; // Dangereux !\n}\n\nComment le Corriger :
\nfunction getCity(user: User | null): string {\n return user?.address?.city ?? 'Unknown';\n}\n\nComment Donner un Retour :
\n« Utiliser ! ici est risqué — si user s'avère être null, une erreur se produira. Remplaçons-le par ?. et ?? — c'est sûr et lisible. »
3. Generics et Types Utilitaires : Ne Compliquez Pas Sans Nécessité
\n\nLes generics sont une fonctionnalité puissante, mais il est facile de trop complexifier les choses. Le relecteur doit surveiller l'équilibre entre flexibilité et lisibilité.
\n\nCe qu'il Faut Vérifier :
\n- \n
- Complexité excessive. Si un generic n'est utilisé qu'une seule fois, il n'est peut-être pas nécessaire. \n
- Utilisation correcte de
extends— contraignez les generics pour qu'ils n'acceptent pas tout. \n - Types utilitaires (
Partial,Pick,Omit,Record) — leur utilisation simplifie le code. \n - Types de retour — une fonction avec un generic \n