begin process at 2010 02 10 07:35:47
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Tutoriaux

 > LES RÈGLES DE LA BONNE PROGRAMMATION EN PHP

LES RÈGLES DE LA BONNE PROGRAMMATION EN PHP


 Information sur la source

Note :
7,8 / 10 - par 41 personnes
7,80 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Tutoriaux Niveau :Débutant Date de création :25/07/2004 Date de mise à jour :23/08/2004 22:07:53 Vu :17 629

Auteur : GRenard

Ecrire un message privé
Site perso
Commentaire sur cette source (100)
Ajouter un commentaire et/ou une note

 Description

Voici un tutorial sur les règles du PHP5 et aussi du PHP4 pour les configurations !
Il est conseillé de les suivre et de ne pas dire "Mais ça marche quand même de la manière que je fais !"
Pourquoi est-ce conseillé de suivre ses règles ? Tout simplement, votre site sera plus portable, et fonctoinnera avec les meilleurs fonctionnalitées.

Voici les règles pour PHP 4 ou 5 avec les variables à respecter.
Vous allez dans votre php.ini et vous modifier ces variables. Si votre site professionel (ou hébergement profesionnel) ne vous permet pas de changer ces variables, je vous conseille de tester le tout chez vous avec les bonnes variables. Ainsi, si vous changez d'hébergeur, et que celui-ci n'a pas les mêmes configurations, vous n'aurez aucun problème à faire fonctionner votre site.

short_open_tag = Off
Cette variable vous oblige à débuter vos scripts avec <?php et non plus <?. La variable short_open_tag va de plus en plus disparaître au cours du temps. Donc c'est à vous de bien programmer et de penser à utiliser <?php au lieu de <?
Attention, vous ne pouvez plus non plus utiliser <?=, il faut utiliser <?php echo
Auparavant, vous pouviez aussi coder immédiatement apres la balise comme <?if, mais maintenant, il faut y mettre un espace : <?php if...

register_globals = Off
Cette variable permet d'améliorer la sécurité de vos sites web. Elle vous oblige à utiliser les variables superglobales au lieu d'utiliser des variables simples.
Lors d'un envoi d'un formulaire, vous spécifiez la méthode et vous devez donc utiliser cette variable comme $_POST['variable'] ou $_GET, au lieu de $variable directement.
Même chose pour les variable $_SERVER, $_COOKIE, $_ENV...

error_reporting = E_ALL
Cette variable vous oblige à bien coder car elle va afficher toutes les erreurs possibles que le site peut générer. Vous avez surement un error_reporting qui empêche les erreurs NOTICE d'apparaître.
Si vous avez un NOTICE qui dit "Unidentified Variable", c'est parce que vous n'avez pas défini cette variable auparavant.
Vous ne pouvez pas faire un echo $_POST['variable'], si $_POST['variable'] n'existe pas auparavant...
C'est pour ca qu'il faut utiliser la fonction isset()
if(isset($_POST['variable']))
$variable = $_POST['variable'];
else
$variable = "";

display_errors = On
Bien que sur certains sites cette variable est à Off car il est dit que pour les sites professionels, il ne doit pas y avoir d'erreur qui apparait.
Si vous codez bien, même si cette variable est à On, il n'y aura pas d'erreur qui apparaîtra ;)

allow_call_time_pass_reference = Off
Avant, cette variable était réglé sur On... Elle permetait de passer à la volé des variables par référance à l'APPEL des fonctions.
Maintenant, si vous voulez passer une variable par référence, vous devez le définir dans la création de la fonction.
Mais au fait ? c'est quoi ca référence ?
Une variable par référence permet de passer un "pointeur" (pour les pro, c'est pas géré comme un pointeur à la base) vers une adresse mémoire.
Mais c'est quoi un pointeur ?
Lorsque vous passez une variable à une fonction (sauf les ressources) vous en faites une copie... Si vous la passez par référence, vous donner l'adresse mémoire de cette dernière. Ce qui a pour influence que vous pourrez modifier le contenu de cette dernière.
Exemple
function test(&$a){
$a = 5;
}
$bou = 3;
test($bou);
// $bou vaut maintenant 5;


Autres conseils :
Ne pas utiliser $_REQUEST... Ceci accepte les $_POST et $_GET. Vous savez d'ou vient votre variable, alors utiliser $_POST ou $_GET !

############################# AJOUT 2 AOUT 2004
Suite aux commentaires reçu dans ce post et dans d'autres, je post ce petit ajout sur les règles de la bonne programmation.

Recherche/Remplacement
Pour faire de la/du recherche/remplacement dans un texte, il est plus rapide d'utiliser les fonctions str_. Si vous devez trouver des choses plus compliqués vous pouvez utiliser ereg_. Par contre, il encore mieux d'utiliser les fonctions preg_ car celles-ci sont plus rapides.

echo/print
Si vous voulez gagner en rapidité, il est préférable d'utiliser echo car print retourne une valeur. Vous pouvez aller voir sur http://www.faqts.com/knowledge_base/view.phtml/aid /1/fid/40.
Par contre, si vous souhaitez formater du texte, il est préférable d'utiliser printf ou sprintf.

SQL
Lors de requète SQL, il est préférable d'utiliser le nom des champs exacts plutot que d'utiliser la clé *. (SELECT * FROM...)
Pourquoi ? Parce que dans votre script, vous n'utiliserez certainement pas TOUS les champs que vous allez obtenir. De plus, si l'ordre des champs change il pourrait y avoir des problèmes avec votre code. (voir plus bas). MÊME si votre sql fais 10 mètres de long parce que vous placez des champs, je pense qu'il est préférable de faire ainsi !
Il est mieux d'utiliser la constantes MYSQL_ASSOC plutot que MYSQL_NUM (ou MYSQLI_...). Pourquoi ? parce que de cette manière, vous allez obtenir $var['champ'] plutot qu'un d'un numéro qui pourrait changer : $var[5].

La concaténation
Il est préférable de concaténer vos variables plutot que de les afficher directement dans vos strings.
Exemple : $var = "Something " . $other;
Plutot que $var = "Something $other";
Ici les 2 vont fonctionner mais il est préférable de faire le premier exemple parce que si vous devez afficher un tableau multidimensionnel par exemple, vous DEVREZ le concaténer. Donc, il suffit de lire "L'art de la Régularité" plus bas.
Je pense qu'il est préférable d'utiliser une concaténation avec des points (.) plutot qu'avec des virgules (,) parce que le standart est quand même le point et que sur php.net vous verrez rarement une concaténation à virgule.

Apostrophe/Guillemet
Lors d'un affichage d'un simple texte, il est dit que c'est plus rapide d'utiliser les apostrophe car PHP ne remplace pas les variables dans le texte entre apostrophes. Par contre ici, il suffit de suivre "L'art de la Régularité" cité plus bas.

include_once
Lorsque vous insérer plusieurs fichiers (include) car vous êtes maintenant rendu au stade ou vous programmer modulairement (oui ca prend du temps). Plusieurs fichiers ont besoin de d'autres pour fonctionner. Donc logiquement, vous les appeler avant. Mais pour être encore plus logique, il serait préférable de faire un include_once au début de ces fichiers qui ont besoin des fichiers précédemment appeler.
Pourquoi ? Parce que comme en C, vous faites des #include afin de montrer que certaines fonctions sont dans d'autres fichiers et vous en aurez besoin. include_once signifie que vous n'appelerai le fichier qu'une seule fois. PHP va savoir si le fichier est déjà chargé. De plus comme avantage, si jamais vous vouler utiliser que le fichier x.php, vous verrez IMMÉDIATEMENT de quels autres fichiers il a besoin.
Question rapidité ? Il est peut-etre vrai que vous perdez quelque milisecondes avec beaucoup d'include_once mais je ne pense pas que ca soit ca qui compte. D'autres vont préferer de faire "// Ajouter le fichier y.php" en commentaire en haut du fichier. Mais il est préférable de faire ces include_once car vous n'aurez pas à modifier le code si vous prenez par exemple les fichiers requis et que vous les déplacez dans un autre dossier !

include/require ?
La différence entre les 2 est que require va emettre une Fatal Error alors que include va emettre un Warning si le fichier à inclure n'est pas trouvé

L'art de la Régularité
Essais d'être régulier dans vos codes. Si vos tableaux vous les appeler avec des apostrophes ($var['test']) et parfois avec des guillemets ($var["test"]), vous ne garderez pas une régularité. Employez une des deux notations et gardez la ! (Ici il est préférable d'utiliser les aportrophe question de rapidité).
Ceci ne vaut pas seulement pour les apostrophes et appel de tableau, mais aussi par exemple les appels de fonctions (FOpen, et fopen font la même chose, mais gardez dont l'habitude de faire que fopen). Même chose avec print et echo.

L'affichage des erreurs (@)
Il est vrai que sur un site web professionel on ne doit pas voir les erreurs. L'utilisation de @ est à proscrire ! Il vaut mieux essayer de trouver le problème plus haut dans votre code plutot que d'executer des lignes et des lignes inutiles...
Par exemple, lors de la connexion à une base de données. Vérifiez si vous êtes connecté avant de faire un query. Même chose pour un fetch_array, vérifier que votre Query est bon ! Ainsi, vous éviterez d'utiliser les @.
La seule utilisation que vous pouvez faire car vous n'avez pas le choix, c'est par exemple à la connexion de la base de données... Ici vous pouvez quand même faire un if, mais il vous sortira un Warning ou une Notice. Vous pouvez cacher ces erreurs, mais gérer les !

Fonctions Modulaires
Une fonction modulaire est une fonction qui peut fonctionner partout ! sans avoir besoin de 3000 autres lignes de code. À l'utilisation de ces fonctions, un utilisateur n'aurait pas besoin de comprendre ce qu'il y a dedans, mais seulement ce que l'on doit mettre et ce qu'il y a en sortie.
Si une fonction doit absolument recevoir du texte, mettez une vérification "si int... transforme le en string". Toutes ces genres de vérification doivent être faites DANS la fonction et pas par l'utilisateur dans son script.
Vous allez dire "Oui mais, c'est moi qui code, je ne suis pas con à mettre un int alors que je sais qu'il faut un string". Ok, mais si d'autres ne font pas expres et placent un int... ?

Fontions Modulaires : La gestion d'erreurs
Une bonne gestion d'erreur sur les fonctions modulaires est très utile. Si vous devez retourner un string par exemple, et qu'il y a une erreur, alors retournez FALSE. En PHP, même chose pour les int... retournez FALSE (pourquoi je dis en PHP ? parce que en C++, si on doit retourner un int, alors on a l'habitude de retourner -1 en cas d'echec par exemple...)
Si votre fonction existe plusieurs points de sorties en tant qu'erreur (des return FALSE) et un return TRUE en tant que réussite, vous pouvez retourner des codes d'erreur. (return 1, return 2...) Ainsi, vous faites un commentaire en haut de votre fonction et vous expliquez ... Si 1 alors ... si 2...
Si cette fonction a bien fonctionné, au lieu de retourner TRUE, vous retournez 0. Zéro signifie que la fonction s'est terminé correctement.

############################# AJOUT 13 AOUT 2004
Fin du Script
À la fin de votre script, assurez vous de fermer toutes les choses que vous avez ouverte lors de son exécution même si la documentation vous affirme que cela se fait tout seul, il est préférable de le faire par vous même.
Par exemple pour les connexions SQL, les fichiers, les classes (créées dynamiquement), ...

PHP5 et les Classes
* Les mots-clés private, public, et protected
Ces mots-clés servent à définir la portées des variables et des fonctions. Sachez que vous ne pouvez pas les utiliser sur les fonctions définies par PHP (ex: __construct()).
private : Les variables ou fonctions private seront accessibles par la classe seulement qui possède la variable ou la fonction.
public : Les variables ou fonctions public seront accessibles dans tout le script ! Ceci est la valeur par défaut des variables et fonctions. Il est déconseillé de l'utiliser partout !
protected : Les variables ou fonctions protected seront accessibles par la classe même ou les classes parentes à celles-ci.

* Les Constructeurs et Destructeurs
Auparavant les constructeurs en PHP5 étaient écrit de la sorte :
function nom_de_la_classe()
et il n'y avait aucun destructeur. Maintenant le constructeur est __construct() et destructeur __destruct(). Sachez que vous ne pouvez les appeler directement.
Aprenez à bien utiliser __destruct() ! Si votre classe ouvre un fichier dans __construct(), eh bien fermez le dans __destruct() !

Classe pour mySQL et mySQLi et autres
Les technologies changeant rapidement ainsi que vos pages, je souhaite pour vous que vous n'ayez pas à retaper tout un code si vous devez changer d'hébergeur !
C'est pour quoi je vous propose la classe suivante :
http://www.phpcs.com/code.aspx?id=24813
Allez y jeter un coup d'oeil


 Conclusion

Si vous avez d'autres questions ou des commentaires, n'hésitez pas à les poser ici.
Maintenant, vous n'avez plus de raison de dire "Mais ca marche quand même" ou de ne pas bien programmer ;)
Si vous postez initié ou expert, essayez dont de suivre ces standards !


 Historique

02 août 2004 17:21:28 :
Quelques Ajouts
03 août 2004 01:54:56 :
Ajout de include/require et Affichage des Erreurs
03 août 2004 02:06:04 :
Ajout de "Fonctions Modulaires", "Fonctions Modulaires : La gestion d'erreurs"
13 août 2004 16:50:07 :
Ajout de - Fin du Script - Les mots-clés private, public, et protected - Les Constructeurs et Destructeurs - Classe pour mySQL et mySQLi et autres
13 août 2004 16:52:01 :
Le lien http://www.phpcs.com/code.aspx?id=24813 ne s'était pas envoyé.
23 août 2004 22:07:54 :
Correction Faute de Frappe

 Sources du même auteur

Source avec Zip Source avec une capture LECTURE/ÉCRITURE DE TAGS ID3 VERSION 1 ET VERSION 2
Source avec Zip GÉRER LES ÉCHAPPEMENTS DE CARACTÈRES SUR TABLEAUX MULTIDIMEN...
Source avec Zip Source avec une capture PROJECT SELECTOR (SÉLECTION FACILE DE PROJET AVEC APACHE) ET...
Source avec Zip Source avec une capture STATISTIQUES DE VOTRE PROJET (NOMBRE DE DOSSIERS, FICHIERS, ...
Source avec Zip Source avec une capture AFFICHAGE TABLEAU AVEC TEMPLATE CLASSE

 Sources de la même categorie

Source avec Zip EXEMPLE DE CRÉATION D'UN SCRIPT D'AUTHENTIFICATION par phpAnonyme
Source avec Zip Source avec une capture N/X API: GOOGLE MAPS DEPUIS PHP VALID W3C par GillesWebmaster
PHP EXTRAIRE DES MAILS D'UN GROS FICHIER LOCAL OU DISTANT par cosmoswarezone1
FORMULAIRE PHP + VERIFICATION + ENVOI DU MAIL par cosmoswarezone1
Source avec Zip Source avec une capture CODE BARE!!! par toutoos

Commentaires et avis

Commentaire de Antidote le 25/07/2004 20:37:21

Merci d'avoir fait l'effort de posté ceci avec les expliquations en prime.

Je pense pour les débutants qui aurait du mal avec le principe des poiteurs on peut utilisé l'attribut "global" qui à le même rendu sur ton exemple.

---------
<?php
function test(){
     global $bou;
     $bou = 5;
}

$bou = 3;

test();

echo $bou;
// affiche 5
?>

Commentaire de GRenard le 25/07/2004 20:49:08

Il est quand même mieux en principe d'utiliser les passages par références des variables si celles-ci font partie intégrante de la fonction et doivent être modifiées...
Si vous ne passez que des variables de langage par exemple, vous pouvez utiliser global.
Dans l'exemple plus haut, comme la fonction ne fait que jouer avec la variable, il est préférable de le passer en référence, bien que le mot clé global fait la même chose dans ce cas.

Commentaire de Antidote le 25/07/2004 21:13:24

exact j'en profitait simplement pour rappeler l'utilisation de global la référance restant l'outil optimum

Commentaire de Inekman le 26/07/2004 02:23:43

Excellent initiative, et très bien expliqué. Si y'a d'autres règles importantes, n'hésite pas à mettre à jour. :-P

Inekman.10/10

Commentaire de manuc le 26/07/2004 09:52:55

Merci GRenard pour cet excellent rappel sur les variables

Commentaire de LocalStone le 26/07/2004 12:44:25

Hééé, dis-donc GRenard, j'ai une question.
J'ai vu sur la doc PHP que y a un autre tableau superglobal : $_GLOBAL. Et à quoi sert-il ? Parce que évidement, je ne m'en souviens plus et comme ça, ça fera profiter tout le monde ...
++ & merci !

Commentaire de WhiteDwarf le 26/07/2004 14:17:52

Inekman a dit : "Excellent initiative, et très bien expliqué. Si y'a d'autres règles importantes, n'hésite pas à mettre à jour. :-P"

J'suis d'accord... bravo ! très bon post, 10/10

Commentaire de GRenard le 26/07/2004 15:48:19

$GLOBALS et non $_GLOBAL peut-etre utilisé dans les fonctions pour accèder à des variables définies globalement (hors de la fonction).
Il est déconseillé d'utiliser cette variable (à mon avis) car vous n'avez qu'à vous même spécifiez que les variables dont vous avez vraiment besoin sans accèder à toutes avec $GLOBALS. Utilisez le mot-clé global.

Commentaire de windu le 26/07/2004 18:51:06

Merci GRenard pour ce tuto sur les variabl & les réglage a fair.. depui le tps kon te voi mettr partou les meme remark sur les réglage (tel que rgister_global...), on aurai dui s'attendr a un tel tuto! loool
Mai g kan meme 1 kestion: kel es la différence entr <? et <?php??? g conai l'utilité de register_global & des otr varaibl ke tu cite mai g tjs cru ke <? et <?php n'etai kune kestion d'abitude, cela change-t-il kelke chose a la sécurité ou a la vitesse d'exécution du script???

Commentaire de Anthomicro le 26/07/2004 21:50:41

Salut ;-)

Je me permet de répondre à la place de GRenard

<? et <?php n'influe en  rien à la vitesse d'exécution, seulement certains serveurs ont leur directive short_open_tags à off, et donc le premier cas ne fonctionne pas. Mettre <?php assure une portabilité maximale du code.

a ++

Commentaire de loupdesombres le 27/07/2004 14:31:52

Bonjour a tous.

LOL Bien joué GRenard... j'en connais qui arrêtera de répéter la même chose dans ses commentaires "initiés" pour faire un simple pointage sur ce tuto.

Just kippin' trying

Commentaire de lumesh le 28/07/2004 10:16:03

autre conseil:

Lors de la récupération de formaulaire prevoir un test de contenu.

Exemple:   $maval = isset($_POST"maval"]) ? $_POST["maval"] : "";

C'est toujours plus sympa et on ne sait jamais.
On pense toujours aux bugs que peut nous sortir nos script mais tres rarement a ce qu'un internaute malveillant peut faire.
Si votre site arrive a parrer les conneries d'un internanute, cest genial et ca lui donne une bonne image.

Et lol pour le $GLOBALS, un truc sympa pour etre sur que tout serra en global:

global($GLOBALS);

la au moins c sur, tout le monde y a acces ! ;)

GRenard, 10/10 :)

Commentaire de f bnkcm le 28/07/2004 22:43:07

Merci GRenard pour ce tuto, j'ai l'impression que tu l'a fait pour ceux qui codent comme moi, ça m'aidera beaucoup à améliorer ma façon alors merci encore.

Commentaire de Cyberboy2054 le 31/07/2004 15:29:47

Pourquoi est ce que maintenant doit-on utiliser
<?php ?> au lieu de <? ?> ?
c'est dû à un probleme de sécurité ?
Sinon je n'en vois pas l'intérêt, ca rallonge le code pour rien.

Commentaire de windu le 31/07/2004 15:38:43

cyberboy2054>>g déjà posé la meme kestion ici.... faut lire les messages des autres avant de poster!!!!

Commentaire de Cyberboy2054 le 01/08/2004 00:00:09

J'ai vu, mais quel intérêt pour les serveurs de t'obliger à taper <?php au lieu de <? ? Ils y gagnent quoi eux, de leur côté ? Et nous, on y gagne quoi ?

Commentaire de loupdesombres le 01/08/2004 00:28:38

Bon, on reprend.   <?    ?>  est un balisage générique indiquant du code a interpréter.
N'importe quel code.  (les déclaration de type de fichier les reprennent aussi par exemple).
Préciser <?php ?> et short_open_tag = Off evite de faire interpréter par php toute les balise <? ?> dans le document (ce qui pourrait entrainer erreur ou perte de temps).
Ce n'est vraiment que pour te montrer un cas ou çà peu bloquer que je dis çà.
Car qui code en php l'indique! Un point c'est tout.
Quel est le plus clair et précis selon toi, entre "Je parle" et "je parle français"...

Commentaire de Cyberboy2054 le 01/08/2004 02:37:06

Ok, je ne savais pas qu'on pouvait mettre autre chose que du php dans <? ?> (débutant inside)
Maintenant je le saurais pour les prochaines fois ...

Commentaire de GRenard le 02/08/2004 04:42:35

Qu'est-ce que tu dis la ?
Relis ce qu'à dit loupdesombres... C'est que c'est plus logique à la base de mettre <?php car on voit bien le mot "php" avec <? on ne le voit pas...
Tu peux avoir <?xml ce qui signifie que c'est du xml et non du php.
Si tu codes avec <?php, tu es sur que ton codes va marcher partout (et les autres règles !). Si tu codes avec <?, ton site va marcher que sur les serveurs ou short_open_tag = Off. Les serveurs ont rien à y gagner... Seulement toi, et nous !

Commentaire de Hellway le 02/08/2004 05:18:08

Pour les <?php, un simple exemple, la déclaration d'un document xml :
<?xml version="1.0" encoding="iso-8859-1"?>

Dans ce cas, on peut être confronté à une erreur et ce type de déclaration va être très fréquente avec les nouveaux standards comme xhtml par exemple.

Commentaire de babid le 02/08/2004 11:14:58

Salut,

D'abord merci à GRenard pour son tuto, et je tiens à te remercier plus particulièrement pour ta class SQL qui m'a fait gagner un temps monstre.
(cf.  http://www.phpcs.com/code.aspx?ID=24813)

Je tenais juste à rajouter des petites questions que je me poses (dont j'ai la solution pour certaine) mais pour compléter ton tuto :

* Question de rapidité d'exécution et d'utilisation :
    - Est-il vrai qu'il vaut mieux écrire ses balises en minuscules plutôt qu'en majuscules ?
    - En php, il vaut mieux utiliser l'apostrophe plutôt que le guillements pour les echo, et l'inverse en JavaScript ?
    - Est-il préférable d'utiliser la fonction echo ou print ?
    - La fonction ereg est plus rapide que la fonction str, mais la fonction preg est plus rapide que ereg ?
    - Quel sont les comparatifs de fonction a utiliser plus que d'autre (dans le même sens que ereg/str/preg) ?

Voila, je pense que ces petites questions complétera ton tuto, car bien codé c'est aussi avec un script qui s'exécute correctement mais aussi rapidement.

Merci pour ta réponse GRenard et bonne continuation.

Babid

Commentaire de babid le 02/08/2004 11:17:52

Désolé, j'avais oublié [10/10] pour ton tuto, en espèrant que les posteurs de codes s'en serviront ;)

Commentaire de Anthomicro le 02/08/2004 12:05:44

Salut ;-)

* Question de rapidité d'exécution et d'utilisation :
>Est-il vrai qu'il vaut mieux écrire ses balises en >minuscules plutôt qu'en majuscules ?

en minuscules

>En php, il vaut mieux utiliser l'apostrophe plutôt que le >guillements pour les echo, et l'inverse en JavaScript ?

tout à fait, et au lieu d'utiliser le point (dans les echos) pour la concaténation il faut utiliser la virgule

>Est-il préférable d'utiliser la fonction echo ou print ?

Echo puisque print retourne 1 (ce qui est plus lent)

>La fonction ereg est plus rapide que la fonction str, mais la fonction preg est plus rapide que ereg ?

Faux, str est plus rapide que ereg.
preg est plus rapide que ereg (car il utilise une syntaxe différente)

>Quel sont les comparatifs de fonction a utiliser plus que d'autre (dans le même sens que ereg/str/preg) ?

par exemple echo au lieu de print, str_replace (pour les règles simples) au lieu de ereg_replace, file_get_contents() au lieu de fopen +fgets+fclose.

a ++

Commentaire de Antidote le 02/08/2004 14:03:28

On pourrai préciser aussi la différence entre ' et " en php. entre " c'est plus lent parce que  la ligne est analyser ex :

<?php

$ma_var = 'tout le monde';

echo 'Bonjour $ma_var';
// affiche Bonjour $ma_var.

echo "Bonjour $ma_var";
// affiche Bonjour tout le monde.
?>



Commentaire de babid le 02/08/2004 14:22:20

Salut,

Tout d'abord merci pour ces précisions claires et rapides.

Je souligne tout de même un point :

Je cite GRenard dans les commentaires de :
http://www.phpcs.com/code.aspx?ID=24899#commentaires

"Je pense que ereg est plus rapide que str, et preg est plus rapide que ereg"

Or Anthomicro, tu dis :
"Faux, str est plus rapide que ereg.
preg est plus rapide que ereg (car il utilise une syntaxe différente)"

Sans aucune méchanceté, faut accorder vos violons !!!

Ensuite Anthomicro, tu écris :
"tout à fait, et au lieu d'utiliser le point (dans les echos) pour la concaténation il faut utiliser la virgule"
Peux-tu me donner un exemple car je ne connais que la concaténation avec le point, et qu'en pense GRenard sur ce point ?

Cela me rappele aussi une question que j'ai oublié de noter :
Faut-il concaténer ou non ? (Je ne parle pas des variables de tableaux car là on est obligé de concaténer)
Exemple :
<?php

$ma_var = 'tout le monde';

//1er méthode
echo 'Bonjour $ma_var';

//2ème méthode
echo 'Bonjour '.$ma_var;
?>

Est-ce que l'une des méthodes à une éxécution plus rapide que l'autre ?

Merci pour vos réponses.
Bye et bonne continuation

Commentaire de Antidote le 02/08/2004 14:45:32

C'était pas plutôt

//1er méthode
echo "Bonjour $ma_var";

?

Commentaire de babid le 02/08/2004 15:16:18

Salut,

Non Antidote, justement, quel est la meilleur méthode entre la concaténation et sans concaténation :
Exemple :
<?php

$ma_var = 'tout le monde';

//1er méthode sans concaténation
echo 'Bonjour $ma_var';

//2ème méthode avec concaténation
echo 'Bonjour '.$ma_var;
?>

Par contre je ne vois pas aussi comment on concaténe avec des virgules ( cf commentaire d'Anthomicro)

Merci

Commentaire de Antidote le 02/08/2004 15:41:25

Je ne connait pas pas de concaténation par virgule en php.

Que te répondre bahid puisque que tes deux méthode n'afficheront pas le même résultat. Elles n'ont rien à voir entre elles ?

Commentaire de babid le 02/08/2004 16:12:45

Merci Antidote pour ta réponse,
Moi non plus je ne connait pas de concaténation par virgule ???!!!!! C'est Anthomicro qui en parle dans son commentaire, je verrai bien quand il répondra.

Ensuite c'est vrai que mon exemple ne donne pas le même résultat, par contre si on a l'exemple suivant :
Exemple :
<?php

$ma_var = 'tout le monde';

//1er méthode sans concaténation
echo "Bonjour $ma_var";

//2ème méthode avec concaténation avec guillemet
echo "Bonjour ".$ma_var;

//3ème méthode avec concaténation avec apostrophe
echo 'Bonjour '.$ma_var;
?>
Quel est la méthode la plus rapide ??
Cette question n'est pas primordiale mais c'est dans l'esprit de bien codé.

Merci pour vos réponses.

Commentaire de Anthomicro le 02/08/2004 16:20:30

C'est mieux de concaténer. Tout dépend aussi du résultat que tu attends.

Pour str qui est plus rapide que ereg il suffit de regarder le site officiel (php.net).

Exemple de concaténation à virgule (marche seulement pour les echos)

echo 'Salut',$visiteur,' !';

par contre $var='Salut',$visiteur,' !'; ne fonctionnera pas, il faut concaténer avec le point dans ce cas là :

$var='Salut'.$visiteur.' !';

D'une manière générale les simples quotes (apostrophes si tu préfères) sont plus rapides que les doubles quotes (guillemets) car tout ce qui se trouve entre les guillemets est interprété, pas ce qui se trouve entre simples quotes.

Bye

Commentaire de babid le 02/08/2004 16:35:21

Merci Anthomicro pour tes réponses,

Franchement je ne connaissais pas cette concaténation avec la virgule. On en apprend tous les jours (heureusement sinon on se ferai chi...). Bon merci pour tous ces conseils, je connaissais certaines réponses mais je n'en étais pas sûr. Ce tuto s'adressant à des débutants, je ne voulez pas les enduire en erreurs donc merci à Anthomicro et Antidote pour vos réponses.

Bonne continuation tout le monde.

Bye

Commentaire de GRenard le 02/08/2004 16:38:20

Désolé de ne pas répondre vite aux questions qui me sont posées, mais j'habite au Québec alors il y a un petit décalage horaire ;)

Pour ereg et str que j'avais mentionné dans une autre source, j'avais écris "Je pense" et bien je ne faisais que penser parce que c'était faux.
Pour l'affichage des variables, pour ma part j'ai toujours utilisé echo, ou sinon printf si j'ai du formatage à faire.
De plus, j'ai toujours utilisé des guillemets pour faire des echo et toujours des . pour mes concaténation... je pense qu'on s'y retrouve mieux avec des points et des virgules. (Surtout que c'est un standard). Pour ce qui est des variables, je les concatène (woua c'est un verbe ?) tout le temps. C'est plus lisible et on garde le "pattern" car lorsqu'on veut afficher un tableau à multiple dimension, on a pas le choix de concatener.

Pour ce qui est des array dans un tableau, j'ai toujours utilisé des apostrophes...
À mon avis, question rapidité, comme le mentionne php.net, la différence entre print et echo est tellement minime.
Vous pouvez faire un tour sur http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40 (anglais).
Donc rendu à ce point, je pense que c'est rendu une question d'habitude et de manière de coder. La seule chose que je dis la dessus, c'est de garder toujours le même pattern. Si vous utilisez print, echo, " ou ' dépendamment de votre humeur, la je pourrais dire que c'est "mal" codé. (Même chose pour les balises par exemple en minuscule et majuscule).

Juste pour une petite précision, les balises en minuscule en HTML c'est mieux pour les prochaines compatibilitées en XHTML.

Commentaire de babid le 02/08/2004 16:52:54

Merci GRenard pour ton point de vue sur les questions, par contre excuse moi mais qu'appeles-tu "pattern" ??

Commentaire de GRenard le 02/08/2004 16:58:21

J'entends cela par ... mmm comment dire en francais...
De garder un style de codage pareil sur tes pages.
Si une fois tu fais <? et l'autre tu fais <?php
Si une fois tu fais fopen() et l'autre fois tu fais FOpen()
Si une fois tu fais echo et l'autre print
Si une fois tu fais $var["test"] et l'autre $var['test']

Ca ne sera pas très joli... Si tu garde une manière de coder, garde la partout.

On dirait babid que tu aimes mes sources ;) merci de me soutenir ;) Si tu adores vraiment ma source Class Langage SQL (http://www.phpcs.com/code.aspx?ID=24813) va poster un petit commentaire ;) parce que beaucoup de monde se demande à quoi ca sert !

Merci à toit babid ;)

Commentaire de GRenard le 02/08/2004 17:22:42

J'ai fais un ajout de quelques petites choses... Pourquoi je l'écris ici ? Parce que vous recevez tous normalement un mail (dans les configs par défaut) lorsqu'un commentaire est ajouté, mais vous ne recevez pas de mail lorsqu'on modifie un code ;)

Vous pouvez continuer à ajouter de beaux commentaires ;)

Commentaire de babid le 02/08/2004 17:27:14

En effet, j'aime bien tes sources, c'est vrai que certains peuvent trouver "chiant" que tu rabaches toujours les mêmes commentaires mais bien codé est aussi un atout pour la portabilité, etc...
Parfois tu t'acharne un peu sur des débutants qui essaient de faire de leur mieux alors vas-y doucement, il y a un début à tout. Toi ainsi que beaucoup d'autre et moi même, ont été débutant. Il faut le temps d'apprendre, soif plus diplomate dans tes commentaires, ils sont instructifs mais ils peuvent en décourager certains.
Ceci dit, je vais aller mettre un commentaire sur ta source de la Class SQL.

Bon courage à tous et bonne continuation

PS:
- c'est vrai que je code beaucoup et que je n'ai guère le temps de poster des sources, mais dès que j'ai l'occasion, j'en mettrai quelques unes.
- pour GRenard particulièrement, continue comme ça (avec plus de tacte sur les commentaiers), tes sources sont vraiement excellentes

Bye

Commentaire de babid le 02/08/2004 17:33:00

Encore une question pour compléter ce tuto. Je pense qu'il faut préciser la différence entre les fonctions include et require. Personnelement, j'utilise require car cela équivaut à include_once. Je ne connais pas la différence de rapidité, de ce coté là je laisse GRenard, Antidote ou Anthimicro, répondre à ça.

Bye

Commentaire de GRenard le 03/08/2004 01:58:33

Tu te trompes... require n'équivaut pas include_once... require_once existe...
J'ai rajouté quelques petites choses dans le tutoriel encore !

Commentaire de thibob le 03/08/2004 12:23:41

suis suppris pour els doubles quotes...
un truc dont vouis avez pas parlé et qui est pourtant très pratique:

echo "blablabla ${mavar}";


sinon sur le tuto, pour les variables à initialiser, mon hébergeur a vite changer la config de son serveur dès qu'il a vu les notice de partout .... sérieusement, vous pensez savoir initialiser toutes vos variables vous ?? ou laors j'aimerais bien avoir une fonction parce que ça complique bien les choses....

Commentaire de oga le 03/08/2004 14:58:32

Bonjour a tous,
je suis tout nouveau ici et j'apprecie a sa juste valeur le travail effectue par GRenard pour assembler ces quelques regles de "bonne programmation", c'est tres utile de ne pas etre oblige de chercher a droite et a gauche ;-)
Deux remarques tout de meme :

1) Une premiere dans le sens de l'intervention de  thibob :
vous pouvez parfaitement integrer un tableau entre des guillemets, grace aux accolades({}), comme ceci :

echo "Valeur : {$monTableau['dim1']['dim2']['dim3']}";
(voir chapitre "Les chaines de caracteres" du manuel PHP, a partir de la version 4)

2) Une seconde sur le chapitre "include_once" du tutoriel : un peu brumeux pour moi ;-) Je n'ai pas tout saisi meme si je comprends la philiosophie de include_once !

Voila,
Encore merci !

Commentaire de Antidote le 03/08/2004 15:10:00

Thibob => d'après ce que je sais "blablabla ${mavar}" équivaut "blablabla $mavar" j'en suis pas sur mais je crois bien.

Bien qu'on (que je ?) pense à initialiser toutes mes variables. Ça doit faire partie de la logique de la programmation.
Avant de faire un gateau tu vas acheter de la farine ?
Avant d'utiliser une variable tu l'initialises.

Je viens du Delphi à l'origine et quand tes sources ne peuvent pas êtres compilées parce que tu n'as pas initialisé une variables je t'assure qu'après tu prend très vite l'habitude de toutes les initialisées.

Comme quoi GRenard mon idée de faire ce "tuto" n'était pas si mauvaise ;)

Commentaire de GRenard le 03/08/2004 18:27:13

Très bonne idée hein de faire un tuto de la sorte :) il devrait rester dans les sources au top du site sur la page d'accueil :P
Pour ce qui est de l'initialisation des variables, oui il faut le faire, ce n'est pas plus long si tu le fais dès le début ! J'ai demandé à mon hébergeur professionel de mettre register_globals à Off. Il l'a fait, mais j'espère juste que ca ne dérangera personne d'autre (peu-etre est-ce effectif que pour moi car c'est des dossier virtuel).
Ensuite pour ce qui est de include_once voici un exemple. (C'est plus logique en C++ mais voici quand même en PHP)

header.php : ce fichier include pleins de fichiers
include("config.php");
... ("db.php");
sessions.php
page.php
stats.php
member.php
...

Et maintenant, si on va voir dans sessions.php
Mes sessions, fonctionnent avec une base de données, je vais donc faire tout en haut du fichier
include_once("db.php");
Ici le fichier ne sera pas "réinclu" parce qu'il l'a déjà été avec le fichier header.php. C'est seulement pour "avertir" que si jamais je prend le fichier sessions.php et que je l'apporte ailleurs, je vais avoir besoin de db.php (et la je pourrais peut-etre voir dans db.php un include_once("config.php");)

Vous comprenez mieux l'histoire des include_once :) ?

J'espère pour vous ;) Mais peu de sites le font parce que c'est déjà une "perte" de temps, et leur script fonctionne que pour LEUR site... et aucun autre. Mais moi par exemple, j'ai une base de site web qui fait environ 1000 lignes, 70ko, 21 fichiers. J'en avais juste marre lorsque je copie cette base vers un autre site de tous rechercher qu'est-ce qui faut que je fasse...

Commentaire de windu le 04/08/2004 00:28:40

GRenard>>bonne explication de incude_once... par contre, il me semblait qu'il existait une autre différence entre require et include (tu dis que c'est seulement le type d'erreur Warning ou Alert): require incluera obligatoirement le fichier alors que include ne le fera que si la ligne ou il se trouve s'exécute (si un include est dans un if qui n'est pas validée alor il ne sera pas inclus mais le require si...)! C'est ce qu'il me semblait avoir vu ici: http://www.nexen.net/docs/php/annotee/function.require.php?lien=require
si cela peut apporter une pierre à l'édifice de ce tuto....

Commentaire de GRenard le 04/08/2004 19:16:00

Arretez de pointer des liens vers nexen... le vrai et l'unique est PHP.net !
Un require ause une Fatal Error, et un include un Warning... à ce point, je n'ai pas expliqué mais une Fatal Error fait arreter un script alors qu'un Warning continue d'executer le script... vous pouvez faire un if avec un @ si vous voulez vous même gérer l'erreur.

Commentaire de Bahanix le 05/08/2004 16:51:53

Grenard c'est pas mal mais ta façon d'écrire fait un peu prétentieuse.
J'ai pas lus les derniers messages, mais désolé, le "Arretez de pointer des liens vers nexen... le vrai et l'unique est PHP.net" je le prend plutot mal : chacun choisi les sites qu'il veut voir, d'autand plus que php.net est anglais !! Alors stp ca ne te concerne pas les sites que les gens vont voir, si qqn veut faire un lien sur nexen ou php.net, il le fait s'il le souhaite.
Au pire si ca te derange tant que ca donne l'équivalent de la page sur php.net...

Idem pour le niveau "débutant", pour le début, ok, mais la fin je te dit que qqn qui débute en php comprendra pas grand chose, moi je prend ca comme "Je connais tellement de choses que cette minuscule fraction de mes connaissances ne méritent que le terme de débutant"...

Commentaire de GRenard le 05/08/2004 18:14:53

First of all, la moitié des sites que le monde pointe sont des sites completement copié de A à Z de php.net
Deuxièmement, tu ne dois pas y aller souvent sur php.net parce qu'il y a plus que l'anglais comme langue, il y en a plus que 20 (dont le francais).
J'ai écris ici les règles de la programmation que je crois qu'il faut suivre. Si tu ne comprends rien, ne les suis pas tout simplement, tu vas les apprendre plus tard.
Ou sinon, si tu es un peu plus intelligent, tu post un commentaire demandant d'expliquer un peu plus une règle comme certain ont déjà fait.

Prétentieux moi ? oui à la réception de ton genre de commentaire... Qui dit que des conneries à mon avis ! (et celui-ci est le mien !!)

Commentaire de thibob le 06/08/2004 19:37:48

Merci Bahanix lol.

GRenard, ce que Bahanix veut dire c que php.net, le vrai est en anglais, les autres ce sont des traductions... donc probablement aussi équivalentes aux autres comme nexen. d'ailleurs nexen héberge php.net...

Antidote: tu peut pas faire ce que tu veut avec un echo "blabla $mavar blabla": comme echo "blabla $mavar[1]";, alorqs que tu voulais jste mettre $mavar et pas la première valeur dans le tableau mavar qui existe pas... du coup tu dois faire echo"blablabla $mavar []"; et c vrai avec plein d'autres choses ... c'éatit un avantage de faire echo'blablabla '.$mavar.'[]'; plus avec les { et } :)

Commentaire de Antidote le 07/08/2004 15:30:58

c'est vrai j'avais pas penser à ça. Merci ^^

Commentaire de rob85 le 09/08/2004 15:19:54

Tout d'abord, barcvo pour ce tutorial qui va en aider plus d'un !!
Je me demandai sune petite chose, il y a un livre intitulé "extreme programming"..., est-ce qu'il y a un rapport avec ce tutorial? est-ce que quelqu'un l'a lu??

Commentaire de GRenard le 09/08/2004 17:42:40

Je n'ai pas lu ce livre, je ne lis plus de livre PHP depuis un bon bout :P
Donc s'il y a une ressemblance, c'est bien malgré moi, ou sinon c'est eux qui m'ont copiés !

Commentaire de windu le 09/08/2004 23:33:17

toujours aussi modeste GRenard... loool!
rob85->On m'a déjà conseillé ce livre mais je ne l'ai pas encore acheté...
Bahanix-> je suis d'accord avec toi, je défends mon droit à pas trop savoir parler anglais, et même à préférer lire un site en français (n'y voyez pas un franchouillard franco-français mais juste un type qui en a marre d'être parfois envahi par l'anglais!). De plus, si nexen ne fait que recopier php.net mais enf rnçaius je ne vois pas où est le problème GRenard, sauf si tu as des actions chez eux... lol

Commentaire de GRenard le 12/08/2004 07:21:18

PHP.net reste à jour avec l'envoie de bugs dans les databases...
Je post parfois des erreurs de traduction.

Lorsque vous voyez dans mes messages le smiley :P, il faut prendre ce message avec un brin d'humour :) Je ne veux pas me penser prétentieux, j'ai seulement fait une blague... j'aurais du mettre pleins de smiley pour que ca soit plus compréhensible :P

Par contre, si vous voyez un :@ (qui n'est pas suivi d'un :P), alors la, c'est que je suis vraiment faché (ca m'arrive rarement !)

Commentaire de psyjc le 13/08/2004 15:11:53

et les variables declaré en static ? :D


( voila comme ca je recevrai pleins de mails :D )

Commentaire de GBHova le 13/08/2004 15:36:09

Ceci est un  tres bon debut...
Dans la section MYSQL, j'aurai personnellement ajouté quelques informations supplementaires :

1 - Fermer proprement ses connexions MYSQL
mysql_close($db);
  
2 - Libérer la mémoire qu'on a utilisé dans nos requêtes d'extraction MYSQL
$ResultatRequete = mysql_query($sql);
//le traitement
...
//libération de la mémoire
mysql_free_result($ResultatRequete);
mysql_close($db);


3 - Créer des requêtes très précises
Lors de requête SQL, il est préférable d'utiliser le nom des champs exactes plutôt que d'utiliser la clé *. (SELECT * FROM...)
Pourquoi ? Parce que dans votre script, vous n'utiliserez certainement pas TOUS les champs que vous allez obtenir. De plus, si l'ordre des champs changent il pourrait y avoir des problèmes avec votre code. (voir plus bas). MÊME si votre SQL fais 10 mètres de long parce que vous placez des champs, je pense qu'il est préférable de faire ainsi !

Exemple :
MAUVAIS :
$sql = "SELECT * FROM table WHERE id = 1";
$resultat = mysql_query($sql);

BON :
$sql = "SELECT nom, telephone, fax, email FROM table WHERE id = 1";
$resultat = mysql_query($sql);



4 - mysql_fetch_array, ajoutez le paramètre MYSQL_ASSOC !
MYSQL_ASSOC = associatif
MYSQL_NUM = numérique
MYSQL_BOTH = associatif ET numérique (par défaut, si on ne précise rien)

Exemple :
while ($ligne = mysql_fetch_array($resultat, MYSQL_ASSOC))


PS : Il est mieux d'utiliser la constantes MYSQL_ASSOC plutôt que MYSQL_NUM (ou MYSQLI_...). Pourquoi ? parce que de cette manière, vous allez obtenir $var['champ'] plutôt qu'un d'un numéro qui pourrait changer : $var[5].



Commentaire de GRenard le 13/08/2004 16:34:16

Pour ce que tu as écri GBHova, c'est des exemples parce que je parle déjà assez de ca dans le tutorial.
Si les personnes ne comprenent pas, elles n'auront qu'à regarder ton post qui est de grandeur disproportionnées comparées aux autres :P
Pour ce qui est du free_result, la je ne pense pas que c'est une question de bien programmer. Il est écrit sur php.net que de l'utiliser si on croit que ca va utiliser trop de mémoire. Alors c'est inutile de l'appeler juste avant de fermer (sql_close);
Par contre, ce qui est de fermer proprement ses connexions, tu as raisons...
Comme pour toutes les fonctions ou les choses créé dynamiquement avec les classes.

psyjc: Tu veux je dise quoi sur les choses déclarées en static ? Comment ca marche ?
Ce n'est pas vraiment une "regle de bonne programmation"

Je pourrais rajouter comment utiliser les mots clés des classes php5.
Je fais ca tout suite :)

Commentaire de jonguignolo le 13/08/2004 17:31:07

j'ai quand meme une petite chose à dire sur ton tuto,
Bravo
^^

Commentaire de derfum le 15/08/2004 15:43:43

Quelques commentaires :
* la version francophone officielle de la documentation est traduite par l'équipe nexen. Alors nexen ou fr.php.net, c'est là même chose (juste le design change, et les gouts et les couleurs...)
* preg/ereg : preg_* sont plus rapides, plus puissantes, offrent des facilités impossibles avec les ereg (preg_match_all pa exemple), mais la syntaxe des masques est (un peu, faites un effort !) plus compliquée. De plus l'extension perg est maintenant (ça remonte à loin le "avant maintenant") une extension de base, donc aucune raison de s'en priver.
* echo/print concatenation virgule/point : bien expliqué sur http://frederic.bouchery.free.fr/?2004/08/10/9-EchoLapinOuTortue En résumé, le pus rapide est ob_start/echo/apostrophe/virgule/ob_end_flush
Je ne détaille pas plus, rendez-vous sur le site.
* MYSQL_ASSOC : la fonction mysql_fetch_assoc est équivalente à mysql_fetch_array et cette option.
* Fin du script : mysql_close est #vraiment# utile si la conncetion n'est plus nécessaire. C'est-à-dire que si le debut du code utilise MySQL mais que la partie suivante du code ne l'utilise plus, un lien MySQL prendra betement des ressources. Mais si les dernières lignes de code utilisent encore une connexion MySQL, mysql_close n'est pas indispensable, voire même une perte de temps (une ligne de plus pour effectuer un mechanisme automatisé tout de suite après)
* quelques fautes de frappe :
...utiliser printf ou sptrinf. -> sprintf
...le nom des champs exactes -> exacts
...l'ordre des champs changent -> change
si votre sql fais 10 mêtres -> mètres

Sinon l'idée de ce tutoriel est très bonne (même si, comme cela a été déjà dit, la partie sur les références et les pointeurs - qui n'existent pas en PHP - est un peu floue)

Commentaire de flashfun le 21/08/2004 19:58:39

Pour ceux qui comme moi n'ont toujours pas compris ce que fait un include_once() :

Son comportement est similaire à include(), mais la différence est que si le code a déjà été inclus, il ne le sera pas une seconde fois.


En l'utilisant on n'est pas obligé de vérifier si le fichier est déjà inclus.

Commentaire de gergalp le 07/09/2004 11:30:00

Je ne vois pas l'intérêt de include_once() dans le sens ou comme nous écrivons le code et donc, nous savons (en principe, c'est le cas) quels fichiers sont inclus et lesquels ne le sont pas, un include() suffit.

Pour moi, le include_once() n'est qu'une manière détournée de ne pas afficher de warning au cas ou le fichier a déjà été inclus et que des fonctions sont redéfinies.

Commentaire de flashfun le 07/09/2004 12:15:42

gergalp:: Je ne suis pas d'accord.
Include_once() est utile quand un page inclus est utilisable seul.
Parfois pour simulé des frames en php, on inclus plusieur pages qui inclus les mêmes fichiers de fonctions.

Commentaire de GRenard le 07/09/2004 13:42:09

La manière que j'explique include_once ici n'est pas obliger d'être suivi ! Ce que je propose c'est de mettre include_once du fichier dans chaque fichier qui utilise le fichier en question... Ceci est pour ressembler au C. Mais vous pouvez utiliser include_once sur un fichier de fonctions ou de classe...
Vous allez dire "Oui mais, je sais que je l'ai inclu, je ne suis pas con !?"... bah alors, à vous de voir "Voulez-vous coder ou bien coder ?"

Commentaire de flashfun le 07/09/2004 13:50:40

Oui,
soit on travail sans ambitions,
soit on se dit que notre travail pourra reservir dans l'avenir (pour nous ou pour quelqu'un d'autre)

Commentaire de windu le 07/09/2004 14:34:50

de plus, le fait de mettre include_once évite aussid des erreur... il peut arriver que plusieurs fichiers appelés dans la meme page-mère appelle eux meme un fichier commun: c'est le cas pour les pages qui nécessitent un accès à la BDD par exemple...
il se peut tout a fait (et c'est meme très souvent le cas si on fait beaucoup d'include) que plusieurs fichiers nécessitent le fichier de connexion ou le fichier possédant la classe MySQL (la je parle dans mon cas, mais je ne suis certainement pas le seul comme ca)

Commentaire de Antidote le 07/09/2004 15:01:17

J'ai un script autonome qui appelle ses propre plugin quand il en a besoin. Chaque plugin appelle de lui même ses propres fichiers sources et communs aux autres de fucntions.
include_once s'avère être plus que pratique dans ce genre de cas pour éviter la redéfinission de fonctions.
Pourquoi ne pas tout appelé une fois au début du script une bonne fois pour toute ?.
Si je créer un autre plugin, j'ai pas besoin d'aller modifier les autres pages. Et côté maintenance c'est plus pratique de savoir qui à besoin de quoi et ainsi de suite. Pour terminé autant limité au maximum le nombre de scripts envoyés au serveur, autant utilisé que le necessaire. Rapidité d'exécution garantie.

Commentaire de gergalp le 08/09/2004 10:35:02

Ce que je voulais dire, c'est que l'on peut tout à fait ne pas appeler plusieures fois le meme fichier même si l'on fait des projets volumineux au niveau du code :

je m'explique :

On peut créer une classe parente qui définit les fonctions de base pour plusieures classes filles qui dérivent les fonctons de la classe parente et en créé de nouvelles.

Comme ca, on a deux fichiers à appeler : celui de la classe parente et celui de la classe fille et toute la suite du script peut se faire avec ces deux fichiers.

Bien sur, on peut avoir plusieures classes pour le même script par exemple une pour le DB, une pour l'affichage des pages, une pour les images...

Commentaire de GRenard le 08/09/2004 13:22:32

Si plusieurs scripts ont besoin de ces classes mais que le script 1 et 3 par exemple, tu peux faire un include_once pour etre sur que tu ne vas pas les inclure plusieurs fois, mais tu essaieras de ne pas l'includre dans le script 2... parce que ca ne servierait à rien.

Commentaire de gergalp le 08/09/2004 20:22:36

Oui, mais il n'y a aucun intérêt à inclure le script 1 dans le script 3 par exemple, enfin, si j'ai bien compris ce que tu voulais dire...

Pour moi il y a 2 types de scripts :
- Les scripts appelés par l'utilisateur
- Les scripts de classes/de fonctions.

Seuls les scripts appelés par l'utilisateur peuvent inclure des scripts de classes/fonctions et seulement des scripts de classes/fonctions.

Tous mes scripts principaux(appelés par les utilisateurs) se trouvent à la racine, les scripts inclus sont dans un dossier include/ et les éventuels modules dans un autre dossier.
La page principale appelle les fonctions dont elle a besoin, soit au début du fichier, soit au moment voulu, et ensuite elle appelle des modules si elle en a besoin.
Si un script de fonctions n'est appelé qu'une fois dans une structure conditionelle, il est inclus au tout début de cette structure, si il est appelé par plusieures structures conditionnelles, soit je fais en sorte qu'il puisse être appelé 1 seule fois en organisant bien le script, soit, je l'apelle au tout début.

Il n'y a q'un seul cas ou le include_once() peut être nécessaire, c'est dans une boucle suivie d'une structure conditionnelle.

Commentaire de windu le 08/09/2004 20:36:39

gergalp> il ya 1 autre cas très courant:
celui de scripts de classes/fonctions (pour reprendre ton expression) qui appelle la classe de connexion à la BDD... comme je le disai dans mon msg précédent
Et là, c'est franchement nécessaire d'utiliser include_once sinon tu peux avoir 1 message d'erreur disant qu'il ne peut pas redéclarer la classe de connexion"

Commentaire de gergalp le 08/09/2004 21:28:21

Non, les classes de connexion à la DB et pour l'affichage des pages sont appelées en tout début de script(si le script et ses fonctions en ont besoin)

Commentaire de Antidote le 08/09/2004 21:45:09

imagine que chaque module que tu as travaille sur des BDD différentes. Deux script utilise la même base de donnée tu fais comment ?

Tu te connecte à toute tes bases à chaque même si ce n'est pas nécessaires ?

Commentaire de loupdesombres le 08/09/2004 21:47:41

Bon, on va faire simple.
Prenons le cas classique d'un gestionnaire de communauté qui différents contenus possibles.
La page d'accueil affiche des news, issues de la base de données, et l'aperçu des derniers messages postés par le forum.
Selon une organisation modulaire, les news sont gérées par un script et l'aperçu du forum par un autre.
Tes deux scripts on donc bsoin d'avoir accès a la base de données.
Deux choix :
- soit tu fais comme tu le proposes, et tu appelles avec include systematiquement ta classe sur la page principale, au risque qu'elle soit inutile, le cas ou le gestionnaire affiche un contenu qui n'en a pas besoin (lorsqu'il affiche par exemple un applet java qui se connecte a un chat IRC).
-soit tu le met dans chacun script, avec include_once; gérant ainsi tout les cas de façon optimale.

Pour finir, d'expérience, il est plus facile de maintenir un site modulaire selon la premiere option, ou chaque module est maintenable de façon autonome sans avoir a se référer au système général, que le deuxième, ou l'on doit toujours maintenir à la fois le gestionnaire du site en même temps que le module.
soit tu appelles ton gestionnaire de connection dans chacun, et

Commentaire de loupdesombres le 08/09/2004 21:50:18

Excusez moi pour les erreurs d'inattention dans le post précédent.
LoupDesOmbres

Commentaire de coockiesch le 09/09/2004 08:51:19

J'avais jamais lu ==> Clap clap clap!!!
Bien utile tout ca!

@++

R@f

Commentaire de Crabmaster le 26/09/2004 00:36:05

Hello,
Juste peut-être pour un complément d'information, j'aime bien cette explication concernant l'utilisation de require ou include: http://frederic.bouchery.free.fr/?2004/07/20/7-RequireOuInclude

De meme que ce lien pour la concaténation: http://frederic.bouchery.free.fr/?2004/08/10/9-EchoLapinOuTortue

Sinon, c'est une très bonne idée de metre les choses au clair, ça me force a coder le plus "logiquement" possible (si j'ose dire...)

++

Commentaire de OriOn le 27/12/2004 22:24:03 administrateur CS

Voilà une source comme on aimerait en voir plus sur phpcs..  A vos claviers !

Commentaire de la_pin le 07/01/2005 18:57:07

merci bcp, ça m'a vraiment aidé pour les bases ! Parfaitement d'accord avec OriOn !

Commentaire de JulioDelphi le 07/01/2005 19:50:37 administrateur CS

ça merite meme d'etre dans un tuto :)

Commentaire de JulioDelphi le 07/01/2005 19:53:21 administrateur CS

allez orion, mets leur une belle note :)

Commentaire de OriOn le 08/01/2005 00:15:56 administrateur CS

Il me semble que j'ai déjà voté sur cette source.

Je te laisse le plaisir de rechercher tout ça dans l'admin hein ;-))

Commentaire de GRenard le 08/01/2005 05:25:34

Sparce que c'est pas marqué une note Admin c'est pour ca :)

Commentaire de OriOn le 08/01/2005 07:51:25 administrateur CS

Maintenant c'est fait ;-)

Commentaire de gomoz le 10/01/2005 15:27:07

merci pour cette mis au point. Parfait pour ceux qui comme ne code que rarement en php et ne veullent pas ce prendre la tête à vérifier les nouveau truc. J'espère qu'il aura plein de MAJ ;)

Commentaire de malalam le 27/01/2005 12:18:28 administrateur CS

Hello,

j'ai suivi un lien d'Exon pour arriver la, je ne l'avais pas vu. Tres bien! Tres bien fait, tres bien explique, et tres utile.
Bref, une bonne initiative bien realisee.

Neanmoins, j'ai lu recemment un article sur je ne sais plus quel site traitant  des chaines de caracteres en PHP. Il y etait notamment dit quelquechose de tres interesant sur les echo.

Tu parles de la concatenation par virgule ou par point, donnant une prefence au point puisque c'est le standard. Certes :
$prenom = "G";
$nom = "renard";
$jemappelle = $prenom.$nom;

Ca se justifie, c'est la seule facon de proceder.

Mais echo est une structure permettant l'affichage des parametres qui lui sont passes. L'affichage.
echo $prenom,$nom;
ne concatene pas $prenom et $ nom. Enfin, ce n'est pas une veritable concatenation, c'est juste l'affichage de 2 variables passees en parametre a echo.
Dans ce cas, je pense que la virgule se justifie.
De la meme maniere :
echo '<div>',$nomprenom,'</div>';
ce n'est pas veritablement une concatenation que l'on veut obtenir; on ne demande pas de variable contenant ces 3 parametres.

La virgule dans ce cas a, de plus, un avantage : echo renvoie juste une chaine, il n'effectue pas d'operation de concatenation, c'est donc un tantinet plus rapide.

Voili :-) C'est en substance ce qu'il y avait dans cet article, et il m'a convaincu.

Commentaire de loupdesombres le 27/01/2005 13:05:50

Jolie précision, qui me permet enfin de comprendre pourquoi il y avait deux codage si proche pour une même opération, et surtout avec des temps d'execution si différents. Cela me semblait étrange. Il n'y en avait tout bonnement pas.

Je reconnais alors tout a fait la justesse et l'interêt de cette écriture.
Elle aura ma préférence et je la recommenderais pour le developpement de petites routines rapides pour lesquelles le temps d'execution est important, voire stratégique (projet de developpement d'ia en environnement concurrentiel  ...)


Je ne l'adopterais cependant pas pour les gros projet standardisé ou une forme de codage consensuelle (et donc actuellement le point) est recommandée, afin de permettre un meilleur travail d'équipe.

Bref tout dépend ou se place le plus la recherche de performance dans le projet (developpement ou production).
Merci encore pour cette précision.

Au fait, avec un poil de retard : Bonne année à tous ^^ !!!!!!

Commentaire de malalam le 27/01/2005 13:19:04 administrateur CS

Je suis d'accord. La difference de performance est sans doute minime. Le mieux est d'adopter une conduite, et de s'y tenir, cela rend les codes plus clairs. C'est necessaire quand on bosse seul...c'est vital quand on bosse en equipe!
Pour ma part, neanmoins, je vais faire une difference entre la veritable concatenation, et le simple affichage de plusieurs chaines de caracteres a la suite. L'idee m'a seduit.

Et merci pour le commentaire :-) Bonne annee aussi!

Commentaire de GRenard le 27/01/2005 13:31:03

Lorsque j'aurai la doc OFFICIELLE de cela, je le rajouterai surement dans ce tutorial... En attendant, peu importe ce qui se passe, suivez la section "L'art de la Régularité" et tout sera correct :)
Perso, j'utilise le .

Commentaire de malalam le 27/01/2005 13:41:19 administrateur CS

Lol...bah, dans la doc OFFICIELLE, echo utilise des virgules pour separer les parametres qu'on lui passe, et sa fonction et d'afficher ces parametres a la suite. Je crois...Et on peut utiliser le point de la concatenation avec, aussi, mais echo n'a pas ete ecrite pour ca. Voila la doc officielle.
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

http://www.php.net/manual/en/function.echo.php

et la ligne tout simple :

echo

(PHP 3, PHP 4, PHP 5 )
echo -- Output one or more strings
Description
void echo ( string arg1 [, string ...] )

Outputs all parameters.

Je ne vois pas d'operateur de concatenation ici...echo rend un output de ce qui lui est passe en parametres, et la separation des parametres se fait par des virgules. C'est la doc officielle d'echo, et donc son utilisation officielle.

On ne parle pas d'officiel ici, pourtant, mais de la meilleure facon de coder, comme tu le dis dans le titre de ton tutoriel.

Commentaire de malalam le 27/01/2005 13:50:44 administrateur CS

Faut que j'arrete de faire des fautes d'orthographe moi... :-(

Je voulais ajouter : je suis tout a fait d'accord avec ton art de la regularite, c'est le plus important, vraiment :-)
Et c'est plus joli les points (plus facile a lire)...mais bon.

Commentaire de loupdesombres le 27/01/2005 15:24:58

> GRenard
Ouuiinnnnn on dit tous pareil et pourtant on se mange le nez, c'est pas bien pas bien pas bien.
On est tous pour l'art de la régularité (qui accepte l'exception, pour la peine qu'elle soit commentée dans la source...).
Alors on se décrispe, je disais juste que je suis content de cette compréhension de cette fausse concaténation qui n'est qu'un passage de paramètres multiples. Etais-je bête, c'était pourtant tellement évident.

Maitenant pour avoir mon avis de manière claire :

Je recommende le point dans un codage clair et structuré, vu que ce dernier s'est imposé comme référence en la matière et donc sera compris par le plus grand nombre dans une optique de partage et de reprise des sources par le suscité plus grand nombre.

> malalam
merci pour cette explication de cette virgule en tant que concaténateur qui me semblais un peu bizarre. Je suis content de comprendre qu'il s'agissait dans le fond qu'un simple passage de paramètres multiples. Pas d'angoisse sur les fôtes, j'essaye aussi de faire de mon mieux mais il en reste toujours un paquet. Je vais d'ailleurs sans doute une rechercher sur leur mode de prolifération une fois que l'on a cliqué sur le bouton envoyé parce que ce n'est quand même pas normal tout çà !!! ^^

>A tous
humour et zen-hatitute serais plutôt agréables plutôt que le ton monte trop vite, surtout sur cette source qui ne mérite pas le moindre nuage.

Commentaire de malalam le 27/01/2005 15:42:26 administrateur CS

Bah, outre que Grenard a un sale caractere quand il s'agit de programmation php, faut dire ce qui est...lol...c'est un sujet passionnel, et qui donc les dechaine forcement, les passions. Mais ce n'est pas tres grave tout ca :-)

Commentaire de grandvizir le 16/02/2005 21:54:31

C'est super clair et pertinent. Avec "display_errors = On", je comprend pourquoi certains codes buggent un max lorsque je les exécute avec EasyPHP, logiciel que je ne peux que conseiller, ainsi que de remplacer tous vos commentaires répétitifs d'ailleurs (<?php, ceci, cela...) par ce lien qui au final est tout à fait intéressant, bien que long à lire. J'ai rarement vu autant de 10/10, et toc, j'en rajoute un !

Commentaire de ImmortalPC le 26/02/2005 11:32:58

Salut,
j'ai lut tout les post et personne n'a de problème avec les \n ou bien personne ne les utilisent ??
Je m'explique avant je codait avec les " ".
ex: $var = "Salut !!!";

Donc si je veux faire un retour à la ligne je met
ex: $var = "Salut !!!\n";

Or avec les ' ' ça marche pas du tout !!!! :'(
ex: $var = 'Salut !!!\n';
Affiche Salut !!!\n

Alors je met :
$var = 'Salut !!!'."\n";
ou
echo 'Salut !!!',"\n";

@++

Commentaire de XoscBloodshed le 25/04/2005 21:13:13

C'est normal, quand tu utilise des simple-quotes `'', l'interpréteur PHP affiche le contenu sans interpréter justement :). Et les chaînes comme `\n' sont considérées comme des variables.

Commentaire de phaphane le 15/06/2005 08:48:29

Excellent tuto ca Grenard, dommage que je ne sois pas tombé dessus avant que je fasse mon script GT Online ca m'aurait éviter l'erreur du <?php par exemple.

Allez une note de 10/10.

Commentaire de Shepard le 17/08/2005 22:25:18

Excellent article ! Merci :)

Juste une chose: Pour les requêtes SQL, si un jour vous passez à PostGreSQL, vous risquez d'avoir de mauvaises surprises en utilisant les quotes ( ' ) pour entourer vos requêtes ... :p

En effet, pour PostGreSQL, les noms de champs peuvent être entourés de guillemets ( " ), donc un truc de ce style:

pg_query('SELECT nom FROM utilisateurs WHERE prenom="Yves";');

génèrera une erreur ... Car PostGreSQL croira que Yves est un nom de colonne et non une valeur.

Donc voilà, vu que j'ai mis du temps à m'habituer à faire l'inverse, et surtout à comprendre quelle était mon erreur, je le mets ici, si à tout hasard quelqu'un aurait le courage de lire autant de commentaires :D :)

Encore bravo pour l'article :)

Commentaire de shoghi le 31/12/2005 01:02:33

Tout simplement Bravo pour ce tuto.


Shoghi

Commentaire de webdeb le 18/12/2007 00:09:05

Je reviens sur le display_errors et la @ :

* le display_errors ne devrait pas rester à On en environnement de production mais uniquement dans un environnement de test. Si un site est bien fait, il devrait être mis en production après avoir suivi le cycle minimal : développement -> test -> (recette) -> production.

Ainsi, en théorie, il ne devrait pas y'avoir de bugs sur le serveur de production. Mais malheureusement dans la réalité, il y'aura toujours une petite erreur pour trainer à un endroit. C'est pourquoi il est recommandé de laisser à On le display_errors en développement pour débugguer plus facilement (cad sans avoir à aller chercher constamment dans les logs de PHP les dernières erreurs générées par l'interprêteur), puis de le désactiver sur le serveur de production. Par contre, en production, on continue de logguer les erreurs dans le fichier de log en vue d'une consultation ultérieure pour débugguer. On peut également mettre à On la directive "ignore_repeated_error" qui permet de ne logguer qu'une seule fois une même erreur générée dans le but de limiter les écritures dans le fichier de logs et également le poids de celui-ci.

* L'arobase est, comme tu le dis, à proscrire mais tu ne dis pas non plus pourquoi. Il y'a tout d'abord la première raison logique que tu évoques, à savoir : traiter les erreurs plutôt que de les cacher. Je suis parfaitement d'accord sur ce point là. En revanche, tu omets de préciser qu'un arobase est extrêmement coûteux en performances. Pourquoi ? Et bien en fait, l'opérateur @ réalise implicitement les opérations suivantes :

- mémorisation de la valeur du display_errors dans une variable temporaire ($tmp = ini_get('display_errors') );
- mise à jour du display errors sur Off : ini_set('display_errors',1);
- interprétation de la ligne
- mise à jour du display errors à On : ini_set('display_errors', $tmp)

Ce qui donne dans la réalité :

$tmp = ini_set('error_reporting', 0);
action();
ini_set('error_reporting', $tmp);

Au final : 2 ini_set() à la suite ====> opérations extrêmement coûteuses.

C'est pourquoi, il est recommandé en production en production :

1/ De ne pas avoir de @ mais de traiter les erreurs qui peuvent être générées
2/ Placer le display_errors sur Off pour ne pas afficher les erreurs s'il en reste que l'on n'a pas détectées.

Voilà pour ce complément d'infos.

++

Hugo.

Commentaire de adoy le 02/01/2008 07:31:06

"Sachez que vous ne pouvez pas les utiliser sur les fonctions définies par PHP (ex: __construct())."

Il me semble que tu peux ;-) sinon comment créer tes singletons et autres designs paterns :-p

Commentaire de GRenard le 02/01/2008 09:20:54

C'est écrit plus bas que tu peux l'utiliser pour constructeur... mais pas en tant que "nom de fonction"...
C'est un peu mal dit je l'avoue... mais ça date de 2004 :)
J'aime bien WEBDEB qui cite la doc, :) car j'en ai écrit une bonne partie...
La doc française est super en retard, tout le monde qui travaillait dessus a d'autres projets pour l'instant et je crois qu'elle est rendue à 50% de synchronisée à ce jour.

Commentaire de kegi le 02/01/2008 21:15:02

Woaw, le 100e commentaire.
S'il y à autant de commentaires, c'est pas pour rien :P

good job (= "bon travail" : pour les "pro-francophones").

Joyeux temps des fêtes.
Kevin.

 Ajouter un commentaire




Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Février 2010
LMMJVSD
1234567
891011121314
15161718192021
22232425262728

Consulter la suite du CalendriCode

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,593 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales