Discussion :

[randoo88]

Bonjour à tous.

Ça fait longtemps que je n'avais pas programmé et je suis en train de m'y remettre et j'avoue que pour certains trucs, je suis un peu perdu. Si je vous écris aujourd'hui, c'est parce que j'ai un bug que je comprends, mais que je ne sais pas comment résoudre.

Alors, j'ai un premier fichier qui contient ma connexion à la base Mysql

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<?php
try
{
	$db = new PDO('mysql:host=########;dbname=##########;charset=utf8', '########', '###########');
}
catch (Exception $e)
{
        die('Erreur : ' . $e->getMessage());
}
?>

Et dans un autre fichier, je veux utiliser une fonction qui fait une requête Mysql.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function nature_nom($id)
{
$sql_nature_nom = "SELECT * FROM geline_compta_nature WHERE nature_id =:id";
$r_nature_nom = $db->prepare($sql_nature_nom);
$r_nature_nom->execute([
	'id' => $id,
	]);
$resultats_nature_nom = $r_nature_nom->fetchAll();
 
// On affiche chaque recette une à une
foreach ($resultats_nature_nom as $resultat_nature_nom) {
 
	return $resultat_nature_nom['nature_nom'];
}
}

Vous aurez peut-être compris, dans ce fichier, je fais un affichage d'un résultat, et il y a des catégories, et cette fonction permet d'afficher le nom de la catégorie, qui est dans une autre table, en partant de l'id de la catégorie qui est enregistré dans la table principale.

En gros, la requête de base affiche un truc du genre



Et je veux créer une fonction pour afficher les noms de Nature, Activité, ...

Alors, mon bug, c'est que ca m'affiche une erreur et je comprend bien que c'est parce qu'il n'arrive pas à récupérer la connexion PDO contenu dans $db.
Fatal error: Uncaught Error: Call to a member function prepare() on null in index.php:11 Stack trace: #0 /index.php(53): nature_nom('1') #1 {main} thrown in index.php on line 11

Suis-je assez clair ? Avez vous besoin d'autres renseignements pour m'aider ?

En tout cas, merci d'avance pour votre aide et ce tout ce qui pourra me faire avancer.

Cordialement
Randoo

[Séb.]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function nature_nom($id)
{
$sql_nature_nom = "SELECT * FROM geline_compta_nature WHERE nature_id =:id";
$r_nature_nom = $db->prepare($sql_nature_nom);

$db ne vaut rien dans ta fonction.

Il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
function nature_nom(PDO $db, $id)
{
    $sql_nature_nom = "SELECT * FROM geline_compta_nature WHERE nature_id =:id";
    $r_nature_nom = $db->prepare($sql_nature_nom);
    ...
}

Et lors de l'appel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$nature = nature_nom($db, $id);

Attention, tu fais un return dons ton foreach(), la boucle ne sera donc pas parcourue entièrement, seul le 1er résultat sera retourné.

[randoo88]

Bonjour Seb,

Merci pour ta réponse. Par curiosité, je ne peux pas faire pour que la variable $db puisse être valable dans la fonction sans devoir la "réintroduire" dans la déclaration de la fonction ?
Sinon, je ferais comme tu me l'as indiqué.

Pour le return, je vois très bien ce que tu veux dire, mais ce n'est pas grave, parce qu'il doit y avoir qu'une réponse possible à chaque fois, donc ce n'est pas grave.

[jreaux62]

Bonjour,

cf messages ci-après...

[cavo789]

Bonjour

Le mot global est à fuir, à l'opposé des bonnes pratiques. On ne sait jamais où est déclarée la variable, quel est son cycle de vie, etc.

Il faut passer la variable comme paramètre à la fonction, ce qui d'ailleurs a été suggéré plus haut.

[mathieu]

Le mot global est à fuir, à l'opposé des bonnes pratiques.

"à fuir" est un peu exagéré, cela peut être utile si on maitrise bien la structure de son application.
une autre façon d'avoir accès à une ressource sans avoir besoin de la passer par chaque contexte est d'utiliser un singleton ce qui revient à peu près au même que d'utiliser une variable globale.

vous pouvez trouver un exemple de classe de ce genre sur cette page :
https://phpenthusiast.com/blog/the-s...pattern-in-php

[jreaux62]

"à fuir" est un peu exagéré, cela peut être utile si on maitrise bien la structure de son application.

+1. Merci.

1- De plus, je ne vois pas ce que ça apporte en terme de sécurité de la passer en paramètre de la fonction.

Par définition, un paramètre est modifiable. Ce qui n'est pas ce qu'on veut ici !

Entre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function ma_fonction($db, ......)
{
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$db = 'machin';
ma_fonction($db, ......);
 
$db = 'truc';
ma_fonction($db, ......);

et :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function ma_fonction(......)
{
   global $db;
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$db = 'machin';
ma_fonction(......);
 
$db = 'truc';
ma_fonction(......);

je ne vois pas bien le gain de "sécurisation"...

MAIS je peux me tromper ! -> MERCI d'expliquer.... SANS moinsser svp...

2- Une solution, qui me semble meilleure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function ma_fonction()
{
   $db = connect_db();
...

[Séb.]

utiliser un singleton ce qui revient à peu près au même que d'utiliser une variable globale

Le singleton "protège" l'instance, alors que $db en global pourrait être écrasée
C'est quand même une grosse différence
Après à l'utilisation, oui, c'est 1 ligne en début de fonction dans les deux cas

[jreaux62]

QUESTION * : et en écrivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
$db = connect_db(); // en début de fichier
 
function ma_fonction()
{
   global $db;
...
}
function ma_fonction_2()
{
   global $db;
...
}

Quels sont les risques (écrasement,...) ?

* (c'est une vraie question)

[Séb.]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
$db = connect_db(); // en début de fichier
 
function ma_fonction()
{
   global $db;
   ...
   Loooongue fonction
   ...
   $db = '(snip)'; // Tellement longue qu'on a oublié le global $db :mouarf:
   ...
}
 
function ma_fonction_2()
{
   global $db;
   echo $db;
}
 
ma_fonction();
ma_fonction_2(); // "(snip)"

[jreaux62]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

   $db = '(snip)'; // Tellement longue qu'on a oublié le global $db :mouarf:

Ah ben c'est sûr...
Mais celui qui fait ça... ne devrait-il pas envisager un autre métier ?...

Cela dit... JE NE JETTE LA PIERRE A PERSONNE !

1- Perso, je travaille SEUL.
Donc, je (pense) MAITRISE(R) MON CODE.

2- Mais effectivement, quand on travaille en équipe (ou que son code est censé être partagé par plusieurs), il vaut mieux prendre toutes les précautions.

[Christophe]

MERCI d'expliquer.... SANS moinsser !

Et merci de ne pas vider un post de sa substance en ne laissant que "bonjour" (post #4)

pas de moinssage de ma part.

[jreaux62]

Je rappelle le concept de :

"Voter contre ce message (inutile, faux, pas d'accord...)"

J'aurais envie de dire : LES TROIS ou rien.


@chrtophe
Quand je me prends 2 ...
Alors oui, je ne laisse que "BONJOUR", puisque, manifestement, mon intervention est... inutile, faux, pas d'accord

[cavo789]

Bonsoir

Tout d'abord, désolé si ma réponse a pu être mal reçue et si le mot "à fuir" a été reçu comme étant violent. Ce n'était nullement mon intention. Je répondais depuis mon smartphone, ce moyen n'étant pas le meilleur pour être prolixe.

Désolé donc si j'ai heurté quelqu'un.

De plus, je ne vois pas ce que ça apporte en terme de sécurité de la passer en paramètre de la fonction.

Je ne pensais pas sécurisation (quoique), je parlais de clean code (code propre).

Lorsque je vois le prototype function uneFonction() {, je "sais" que cette fonction n'utilise aucun paramètre et je présume donc qu'elle va utiliser des propriétés de sa classe (si uneFonction est une méthode d'une classe) ou qu'elle pourrait accéder à des variables globales types $_POST ou $_SESSION (quoique l'accès direct à ces variables est une mauvaise pratique (dans le sens clean code)).

Je comprends bien ton global $db; mais, c'est quoi $db ? C'est chaîne de caractères ? Un chiffre ? Un objet (et si oui, lequel) ? Est-ce que cette variable est initialisée ?

Par contre function uneFonction(PDO $db) { m'apprends beaucoup : je sais que si je veux appeler cette fonction, je dois lui donner un paramètre qui doit être de type PDO et qui doit être initialisé (si je voulais autoriser une valeur nulle alors j'aurais écris function uneFonction(?PDO $db) {Quand je vais programmer (p.ex. en utilisant Visual Studio Code ou autre); si j'écris uneFonction(); pour appeler la fonction, l'éditeur va immédiatement m'alerter qu'il faut que je lui passe un paramètre. Et uneFonction('YoupieYeah'); va également jeter une erreur puisqu'il voit que je passe une chaîne de caratères alors qu'il sait (je lui ai appris) que ma fonction s'attends à un objet PDO ayant été initialisé (du coup, tu me vois venir, si je vais $db=null; uneFonction($db); il va tout autant rouspéter.

L'utilisation d'arguments typés va être (vraiment très fortement) une aide plus que précieuse pour moi d'abord mais aussi toutes les personnes qui vont me lire et même, bien sûr, les outils automatique comme php-cs-fixer, phan, phpstan, rector, psalm, ... qui seront bien mieux guidés. A la lecture du mon code, ils vont pouvoir me proposer des améliorations, vont pouvoir mettre en évidence des erreurs (j'aurais utilisé Notepad et donc zéro alerte comme indiqué dans le paragraphe plus haut), ...

Si j'ai un code legacy et que je change ma fonction après coup uneFonction(); vers function uneFonction(PDO $db) {, l'éditeur mais aussi chaque outil susmentionné vont immédiatement m'alerter. Je réduis donc fortement les bugs.

Des outils comme Php documentor vont aussi tirer profit du passage de paramètres typés pour me générer une doc de qualité.

Bref, que du positif.

Pour revenir à global que j'ai abandonné depuis plus de dix ans; quand tu déclares global $db;, on ne sait donc pas ni son type (int, string, PDO, ...) ni où (dans quelle fonction / script cette variable a été initialisée). Au moment où j'appelle la fonction, sais-je si $db est initialisé ? Il me semble que non (je me trompe peut-être, je n'utilise pas cette syntaxe). Si je lis ton code et donc ta fonction (=si je fais du code review); je suis sacrément ennuyé non ? Ah ok, une variable globale est utilisée. Ok mais ... (quel est son type et sa valeur ?).

Je suppose que, dans une situation réelle, maFonction serait une méthode d'une classe et que j'utiliserais le constructeur pour lui passer l'instance $db (dans l'optique de faire du Content Dependancy Injection càd d'externaliser l'ouverture de la base de données et faire que la classe soit agnostique sur la DB utilisée).

MAIS je peux me tromper ! -> MERCI d'expliquer.... SANS moinsser !

Ah mais surtout pas ! Cela ne me serait pas venu à l'esprit, au contraire, c'est l'occasion de discuter d'un sujet important et de voir comment chacun code pour répondre à un besoin. Je lirais vos réponses avec grand intérêt.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function ma_fonction()
{
   $db = connect_db();
...

Ben je ne suis pas sûr. Je dirais que la connexion doit se faire une seule fois (et pas dans chaque fonction où tu aurais besoin de $db. Ainsi tu peux capturer en un seul endroit la gestion des erreurs (la connexion n'a pas réussie pour x ou y raisons).

Dans l'exemple que tu donnes ci-dessus et que, perso je préfère largement à l'utilisation de global, tu crées une dépendance assez forte entre ta fonction et la seconde connect_db. Avec un passage de paramètre, je me donne plus de flexibilité en décidant, avant d'appeler la fonction, si je souhaite utiliser la base de données X ou la seconde Y (c'est l'idée du Content Dependancy Injection); rendre la fonction appelée moins dépendante et plus flexible.

QUESTION * : et en écrivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
$db = connect_db(); // en début de fichier
 
function ma_fonction()
{
   global $db;
...
}
function ma_fonction_2()
{
   global $db;
...
}

(ne dois-tu pas d'abord déclarer global $db; avant son utilisation ? (je ne sais plus))

Un truc me chipote dans ton code proposé ci-dessus (toujours avec un focus important sur le concept de clean code) : tu aurais un code exécutable (ta ligne 2) avant d'avoir des déclarations (lignes 4 à 13). Oui, oui, c'est juste de l'organisation de code, je sais mais "logiquement" on déclare d'abord les fonctions avant le premier code exécutable (donc, concrètement, je mettrais ta ligne 2 à la fin du fichier).

Mais aussi, cette ligne 2 est "hors fonction". Demain si tu souhaites convertir ton code dans une classe; tu vas devoir revoir ton code; ta ligne 2 serait p.ex. dans la fonction __construct();; du coup, tu vas probablement te dire que $db serait quand même mieux déclarée comme étant un attribut de ta classe (et plus une variable "isolée"). Ah oui, mais souci, du coup, tu vas devoir modifier chaque fonction où tu aurais ton global $db; qui n'existe plus. Si on avait utilisé un paramètre, le corps même des fonctions seraient inchangés. Tu réduirais alors la charge de travail de refactorisation. Maintenant, si $db est un attribut, on n'utiliserait plus non plus des paramètres mais on ferait appel à $this->db (mais ce n'est pas obligatoire).

Je pense (mais ce n'est que mon avis personnel) qu'il est préférable de s'obliger à coder de manière la plus stricte possible (je pense au typage fort, au forçage du numéro de version cible de PHP (forcer PHP 8.1 p.ex. dans ses paramètres), je pense à l'utilisation d'outils comme ceux mentionnés plus haut (phan, phpstan, pslam, rector) afin de voir où ils vont rouspéter et adapter son code dans ce sens). Je pense aussi qu'on ne sait pas de quoi demain sera fait et qu'il faudrait songer dès aujourd'hui au futur (programmer des classes objets, favoriser l'injection de dépendances, ...), ... Cela va amener à avoir un code propre (clean code), lisible par un humain mais aussi et surtout la machine (l'éditeur, les outils) et, objectif souhaité, le rendre plus facilement maintenable et extensible.

Lire plus sur le clean-code : https://github.com/jupeter/clean-code-php. Un chouette exemple est justement donné pour l'utilisation d'une variable globale (https://github.com/jupeter/clean-cod...d-side-effects) où il démontre que $db pouvait valoir db1 (connexion vers une DB1) à l'entrée de la fonction et qu'on peut changer vers db2 "ni vu ni connu" càd sans peut-être même l'avoir voulu. L'exemple montre aussi que la variable $name était une chaîne de caractères à l'entrée et hop, c'est devenu un array à la sortie. Ce type de bug est mortel à retrouver dans des centaines de fichiers php, des milliers de ligne de codes.

Alors oui, je ne laisse que "BONJOUR", puisque, manifestement, mon intervention est... inutile, faux, pas d'accord

Aucun de ma part et je vais plussoyer pour tenter d'équilibrer ;-)

[jreaux62]

@cavo789

Ça fait déjà un moment que je demande que les ne soient plus anonymes.
CA permettrait au moins d’ÉCHANGER LES POINTS DE VUE, en toute INTELLIGENCE...

[cavo789]

Ça fait déjà un moment que je demande que les ne soient plus anonymes.

Il y a une bonne année (voici mon post d'alors https://www.developpez.net/forums/d2...aux/like-post/), j'ai posté sur le forum une question quant à savoir s'il était possible d'avoir les noms des personnes qui avaient "plussoyés" et de mémoire j'avais reçu une réponse dans le style "parce que" càd que le modérateur n'avait pas pris le soin d'expliquer ce choix d'anonymiser.

(Sachant que le forum ici est vBulletin, je peux certifier que vBulletin offre bien la possibilité d'afficher les noms; je suis admin d'un forum sur Joomla)

Ma demande visait à savoir si, quand on réponds à une question et que le demandeur initial ne réponds pas par un "Cool, merci, ça fonctionne maintenant" mais qu'on voit juste un "+1"; est-ce que ce +1 est le demandeur (auquel cas on sait que nous avons réussi à l'aider) ou quelqu'un qui pense que la réponse apportée semble être correcte.

En l'absence d'une réaction du demandeur initial et en présence d'un +1; ce serait sympa et utile pour tout le monde de savoir si c'est le demandeur qui a plussoyé. Fin de non recevoir; je n'ai pas insisté.

[randoo88]

Bonsoir à tous,

Je ne pensais pas que ma petite question amènerait un tel débat. Pour ma part, j'ai appris le PHP il y a une vingtaine d'année, tout seul, en autodidacte, et j'ai arrêté pendant pas mal d'années pour des raisons de temps, d'envie, ...
J'essaye de mis remettre, pour des besoins purement personnel, genre, me faire un calendrier, ou dans l'exemple présent, faire la compta d'une association.

J'avoue que je suis pas mal perdu quand je lis certains codes d'aujourd'hui, parce rapport à ce que j'ai pu connaître. J'essaye tant bien que mal déjà, d'utiliser le principe MVC. Lol

Dans les souvenirs, je n'avais pas ce pb de connexion à la base avec les fonctions mylsq() qu'on utilisait à l'époque. Qu'est ce qui a changé ?

Et par curiosité, est ce que de déclarer ma fonction en privé ou public, ca change quelque chose ?
Ou si je créé une fonction pour me connecter à ma base Mysql en la déclarant public, ca changerait quelque chose ?

En tout cas, merci beaucoup pour votre aide et pour les réponses que vous m'apportez.
Guillaume

PS : Je ne veux pas que ce post devienne une bataille. De nos jours, il est encore plus important de garder un débat apaisé. Merci

[cavo789]

En effet, PHP a fortement évolué; au départ un langage "laxiste" (on peut ne pas déclarer des variables, on peut assigner du texte puis un chiffre puis une date puis ..., etc.) et au fil du temps devient un langage plus strict (et donc meilleur). Plus on évolue 5 vers 7 et maintenant PHP 8, plus on a un langage qui n'a certainement plus à rougir de la comparaison.

Pour ta question public / private, cela n'est à prendre en compte que pour les classes (programmation orienté objet aussi nommé POO).

Une classe va avoir des fonctions internes (et donc privées) : on ne veut pas que quelqu'un puisse les appeler (p.ex. j'aurais une fonction debugObject() que je ne veux pas pouvoir être appelé avec voiture->debugObject()). Par contre, je souhaite que voiture->diagnostic() soit public càd que l'on puisse faire un diagnostic à tout moment. La notion public / private ne porte donc que sur la visibilité d'une fonction (nommée méthode ici). Plus un objet à des méthodes publiques, plus il y aura de risques de cassures en cas d'adaptation de l'objet. Il faut donc (clean code) veiller à offrir en public juste ce qui doit l'être. Le postulat est donc : une fonction est private ... à moins qu'elle soit publique. Et non le contraire.

[randoo88]

Ok, merci. J'ai pas tout compris, mais j'ai compris que ca ne concernait pas mon problème de départ. Lol

[jreaux62]

Bonjour,

... j'ai compris que ca ne concernait pas mon problème de départ. Lol

=> voir message suivant !