Internationalisation des applications C++ : créez un logiciel de classe mondiale

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Revue de Code en TypeScript : Ce qu'il Faut Vérifier et Comment Donner un Retour d'Expérience Concret

\n\n

La 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\n

1. Types et Annotations : Évitez `any` et Utilisez la Rigueur

\n\n

La 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.

\n\n

Ce qu'il Faut Vérifier :

\n
    \n
  • Présence de any. Chaque any doit ê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 string là où un enum ou un type union est nécessaire.
  • \n
  • Typage excessif. TypeScript peut inférer les types. N'écrivez pas const x: number = 5 — écrivez const x = 5.
  • \n
  • Paramètres stricts. Vérifiez que tsconfig.json contient strict: true, noImplicitAny, strictNullChecks activés.
  • \n
\n\n

Exemple de Mauvais Code :

\n
function processData(data: any) {\n  return data.name.toLowerCase();\n}
\n\n

Comment le Corriger :

\n
interface User {\n  name: string;\n}\n\nfunction processData(data: User): string {\n  return data.name.toLowerCase();\n}
\n\n

Comment Donner un Retour :

\n

Au 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. »

\n\n

2. Gestion de null et undefined : strictNullChecks Sauve des Vies

\n\n

Les 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.

\n\n

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
\n\n

Exemple de Mauvais Code :

\n
function getCity(user: User | null): string {\n  return user!.address!.city; // Dangereux !\n}
\n\n

Comment le Corriger :

\n
function getCity(user: User | null): string {\n  return user?.address?.city ?? 'Unknown';\n}
\n\n

Comment 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. »

\n\n

3. Generics et Types Utilitaires : Ne Compliquez Pas Sans Nécessité

\n\n

Les 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\n

Ce 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

Blogs

Book Recommendations