C'est un principe de conception fondamental : passer les données en paramètres (plutôt que d'accéder à des variables globales depuis les fonctions) rend le code plus fiable, testable et maintenable — voici pourquoi, et pourquoi les globales sont à éviter. Le comportement de la portée en PHP : une variable définie DANS une fonction est locale (invisible dehors), et une variable définie DEHORS n'est PAS automatiquement accessible dans une fonction. C'est VOULU : chaque fonction a son espace isolé. Pour utiliser une variable externe dans une fonction, on POURRAIT la déclarer global (mot-clé qui donne accès à une variable globale) — mais c'est une MAUVAISE pratique dans la plupart des cas. Pourquoi les variables GLOBALES (accès via global) sont problématiques : (1) Couplage caché et dépendances invisibles. Une fonction qui accède à une variable globale a une DÉPENDANCE CACHÉE : rien dans sa signature (son nom et ses paramètres) n'indique qu'elle utilise cette variable externe. Pour comprendre ce dont la fonction a besoin, il faut lire tout son corps. Cela rend le code difficile à comprendre et à utiliser (« que faut-il pour appeler cette fonction ? »). (2) Effets de bord imprévisibles. Une fonction qui LIT ou MODIFIE des globales peut avoir des effets à distance (modifier une variable utilisée ailleurs), causant des bugs difficiles à traquer (« pourquoi cette variable a changé ? »). Les fonctions deviennent imprévisibles (leur comportement dépend d'un état externe caché). (3) Difficulté à TESTER. Une fonction qui dépend de globales est difficile à tester isolément : il faut mettre en place l'état global attendu, et les tests peuvent interférer entre eux (état partagé). Une fonction avec des paramètres explicites se teste facilement (on passe des valeurs, on vérifie le retour). (4) Réutilisation limitée. Une fonction couplée à des globales spécifiques est difficile à réutiliser ailleurs (elle attend un contexte global particulier). (5) Concurrence et état partagé. Les globales créent un état partagé, source de bugs et de complexité. Pourquoi passer les données en PARAMÈTRES est meilleur : (1) Interface EXPLICITE. Les paramètres DÉCLARENT ce dont la fonction a besoin. En voyant function calculerTVA($montant, $taux), on sait immédiatement ce qu'il faut lui fournir. La fonction est auto-documentée et facile à utiliser. (2) Prévisibilité (fonctions « pures »). Une fonction qui ne dépend QUE de ses paramètres (et ne modifie rien d'externe) est PRÉVISIBLE : pour les mêmes entrées, elle donne toujours le même résultat, sans effet de bord. C'est plus facile à comprendre, à raisonner, à déboguer. (3) Testabilité. On teste facilement (passer des entrées, vérifier la sortie), sans mise en place d'état global, sans interférence entre tests. (4) Réutilisation. Une fonction avec des paramètres explicites se réutilise dans n'importe quel contexte (on lui passe les bonnes données). (5) Découplage. La fonction ne dépend pas d'un état global, elle est autonome — plus modulaire, plus maintenable. Comment passer les données correctement : (1) Passez en PARAMÈTRES tout ce dont la fonction a besoin (les données à traiter, la configuration). (2) RETOURNEZ le résultat (via return) plutôt que de modifier des variables externes. Le flux est clair : entrées (paramètres) → traitement → sortie (retour). (3) Utilisez des paramètres par défaut pour les valeurs optionnelles. (4) Pour des données structurées, passez des tableaux ou des OBJETS (niveau 3) — un objet peut regrouper des données liées et leurs comportements (une meilleure façon d'organiser l'état que des globales). (5) Pour la configuration partagée (base de données, réglages), utilisez des approches propres (injection de dépendances, conteneurs de services — que vous verrez avec les frameworks) plutôt que des globales. Les rares cas où l'état « global » est légitime : certaines choses sont légitimement partagées (une connexion à la base, une configuration) — mais on les gère PROPREMENT (injection de dépendances, services, constantes pour les valeurs fixes), pas via des variables globales anarchiques. Les frameworks (niveau 4) fournissent des mécanismes structurés pour cela. En résumé : passez les données en PARAMÈTRES (et retournez les résultats) plutôt que d'accéder à des variables globales, car cela rend les fonctions explicites (interface claire), prévisibles (pas d'effet de bord caché), testables (isolées), réutilisables (autonomes) et maintenables (découplées). Les globales créent des dépendances cachées, des effets de bord imprévisibles, et compliquent tests et réutilisation — à éviter. La portée locale de PHP (isolation des fonctions) est une bonne chose : embrassez-la en passant les données explicitement. Ce principe (interfaces explicites, fonctions prévisibles, découplage) est fondamental en programmation et vous servira bien au-delà de PHP — c'est une marque de code propre et professionnel.

Oui, typer vos paramètres et retours est fortement recommandé en PHP moderne — c'est une bonne pratique qui rend votre code plus robuste, lisible et sûr, avec un coût minime. Voyons ce que cela apporte concrètement. Rappel : PHP est à typage DYNAMIQUE (le type suit la valeur, pas de déclaration obligatoire). Mais PHP moderne permet de DÉCLARER les types (typage optionnel mais recommandé) : le type des paramètres (function f(int $a, string $b)) et le type de retour (: int après les parenthèses). On peut même activer le mode STRICT (declare(strict_types=1); en haut du fichier) pour un typage rigoureux. Ce que le typage apporte : (1) Détection d'ERREURS. Si vous appelez une fonction typée avec un mauvais type (passer une chaîne là où un entier est attendu), PHP lève une ERREUR CLAIRE (surtout en mode strict) — au lieu de laisser passer silencieusement une valeur qui causerait un bug plus loin, difficile à traquer. Le typage attrape ces erreurs TÔT, au point d'appel, avec un message précis. (2) DOCUMENTATION implicite. Les types DÉCRIVENT la fonction : function calculerTVA(float $montant, float $taux): float dit clairement « donne-moi un montant et un taux (des flottants), je te renvoie un flottant ». On comprend l'interface sans lire le corps. C'est une documentation vivante et fiable (contrairement aux commentaires qui se périment). (3) Meilleur OUTILLAGE (autocomplétion, analyse). Les éditeurs (VS Code, PhpStorm) et les outils d'analyse statique EXPLOITENT les types : autocomplétion précise (l'éditeur sait quel type est une variable, propose les bonnes méthodes), détection d'erreurs de type AVANT l'exécution (analyse statique), navigation, refactoring plus sûrs. Un vrai gain de productivité et de fiabilité au quotidien. (4) ROBUSTESSE. Le code typé est plus fiable : les erreurs de type (une source fréquente de bugs) sont attrapées, les fonctions reçoivent ce qu'elles attendent, le comportement est plus prévisible. (5) Clarté d'INTENTION. Typer exprime vos intentions (« cette fonction travaille avec des entiers ») et impose une discipline qui améliore la conception. (6) Facilite la MAINTENANCE et le travail en équipe. Sur un gros projet ou à plusieurs, les types clarifient les contrats entre les parties du code, préviennent les erreurs d'intégration, et documentent. Le bénéfice croît avec la taille du projet. Les types disponibles : types scalaires (int, float, string, bool), array, les classes/interfaces (typer par un type d'objet), void (retour sans valeur), les types NULLABLES (?int = int ou null), les types UNION (PHP 8 : int|string), mixed (n'importe quoi, à éviter si on peut préciser). PHP moderne offre un système de types riche. Le mode STRICT (declare(strict_types=1);) : sans lui, PHP tente de CONVERTIR les types (mode « coercitif » : passer '5' à un paramètre int le convertit en 5) — pratique mais moins rigoureux. Avec le mode strict, les types doivent correspondre EXACTEMENT (passer '5' à un int lève une erreur) — plus rigoureux et prévisible. La bonne pratique moderne est d'ACTIVER le mode strict (declare(strict_types=1); en haut de chaque fichier) pour un typage sûr, et de convertir explicitement quand nécessaire (contrôle). Le « coût » du typage : (1) un peu plus à écrire (les annotations de type) — minime. (2) Parfois, gérer les conversions explicitement (en mode strict) demande un peu de rigueur — mais c'est justement ce qui évite les bugs. Le coût est faible, les bénéfices importants. Recommandation : (1) TYPEZ vos paramètres et retours — c'est une bonne pratique du PHP moderne, adoptée par les projets et frameworks sérieux. (2) ACTIVEZ le mode strict (declare(strict_types=1);) pour un typage rigoureux. (3) Profitez des types riches (nullables, unions) pour exprimer précisément vos intentions. (4) Utilisez un éditeur qui exploite les types (autocomplétion, analyse) — vous en tirerez un bénéfice quotidien. (5) Considérez aussi les outils d'ANALYSE STATIQUE (comme PHPStan, Psalm) qui, en s'appuyant sur les types, détectent des bugs avant l'exécution — un atout majeur pour la qualité (à découvrir quand vous serez plus avancé). En résumé : oui, typez vos paramètres et retours (et activez le mode strict) — c'est fortement recommandé en PHP moderne. Cela apporte la détection d'erreurs de type (tôt, avec des messages clairs), une documentation implicite (les types décrivent l'interface), un meilleur outillage (autocomplétion, analyse statique), de la robustesse et de la clarté. Le coût est minime (quelques annotations), les bénéfices importants (moins de bugs, code plus lisible et maintenable). Le typage est l'un des grands apports du PHP moderne (7/8) qui l'ont fait passer d'un langage « laxiste » à un langage robuste. Adoptez-le dès vos premières fonctions : c'est une habitude qui améliore durablement la qualité de votre code et vous rapproche des standards professionnels.