LES RÈGLES DE LA BONNE PROGRAMMATION EN PHP
cs_Antidote
Messages postés
163
Date d'inscription
lundi 29 septembre 2003
Statut
Membre
Dernière intervention
8 mai 2010
-
25 juil. 2004 à 20:37
kegi Messages postés 164 Date d'inscription jeudi 23 octobre 2003 Statut Membre Dernière intervention 25 août 2008 - 2 janv. 2008 à 21:15
kegi Messages postés 164 Date d'inscription jeudi 23 octobre 2003 Statut Membre Dernière intervention 25 août 2008 - 2 janv. 2008 à 21:15
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/24870-les-regles-de-la-bonne-programmation-en-php
https://codes-sources.commentcamarche.net/source/24870-les-regles-de-la-bonne-programmation-en-php
2 janv. 2008 à 21:15
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.
2 janv. 2008 à 09:20
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.
2 janv. 2008 à 07:31
Il me semble que tu peux ;-) sinon comment créer tes singletons et autres designs paterns :-p
18 déc. 2007 à 00:09
* 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.
31 déc. 2005 à 01:02
Shoghi
17 août 2005 à 22:25
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 :)
15 juin 2005 à 08:48
Allez une note de 10/10.
25 avril 2005 à 21:13
26 févr. 2005 à 11:32
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";
@++
16 févr. 2005 à 21:54
27 janv. 2005 à 15:42
27 janv. 2005 à 15:24
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.
27 janv. 2005 à 13:50
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.
27 janv. 2005 à 13:41
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.
27 janv. 2005 à 13:31
Perso, j'utilise le .
27 janv. 2005 à 13:19
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!
27 janv. 2005 à 13:05
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 ^^ !!!!!!
27 janv. 2005 à 12:18
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 '
',$nomprenom,'
';
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.
10 janv. 2005 à 15:27
8 janv. 2005 à 07:51
8 janv. 2005 à 05:25
8 janv. 2005 à 00:15
Je te laisse le plaisir de rechercher tout ça dans l'admin hein ;-))
7 janv. 2005 à 19:53
7 janv. 2005 à 19:50
7 janv. 2005 à 18:57
27 déc. 2004 à 22:24
26 sept. 2004 à 00:36
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...)
++
9 sept. 2004 à 08:51
Bien utile tout ca!
@++
R@f
8 sept. 2004 à 21:50
LoupDesOmbres
8 sept. 2004 à 21:47
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
8 sept. 2004 à 21:45
Tu te connecte à toute tes bases à chaque même si ce n'est pas nécessaires ?
8 sept. 2004 à 21:28
8 sept. 2004 à 20:36
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"
8 sept. 2004 à 20:22
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.
8 sept. 2004 à 13:22
8 sept. 2004 à 10:35
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...
7 sept. 2004 à 15:01
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.
7 sept. 2004 à 14:34
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)
7 sept. 2004 à 13:50
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)
7 sept. 2004 à 13:42
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 ?"
7 sept. 2004 à 12:15
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.
7 sept. 2004 à 11:30
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.
21 août 2004 à 19:58
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.
15 août 2004 à 15:43
* 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)
13 août 2004 à 17:31
Bravo
^^
13 août 2004 à 16:34
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 :)
13 août 2004 à 15:36
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].
13 août 2004 à 15:11
( voila comme ca je recevrai pleins de mails :D )
12 août 2004 à 07:21
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 !)
9 août 2004 à 23:33
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
9 août 2004 à 17:42
Donc s'il y a une ressemblance, c'est bien malgré moi, ou sinon c'est eux qui m'ont copiés !
9 août 2004 à 15:19
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??
7 août 2004 à 15:30
6 août 2004 à 19:37
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 } :)
5 août 2004 à 18:14
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 !!)
5 août 2004 à 16:51
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"...
4 août 2004 à 19:16
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.
4 août 2004 à 00:28
si cela peut apporter une pierre à l'édifice de ce tuto....
3 août 2004 à 18:27
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...
3 août 2004 à 15:10
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 ;)
3 août 2004 à 14:58
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 !
3 août 2004 à 12:23
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....
3 août 2004 à 01:58
J'ai rajouté quelques petites choses dans le tutoriel encore !
2 août 2004 à 17:33
Bye
2 août 2004 à 17:27
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
2 août 2004 à 17:22
Vous pouvez continuer à ajouter de beaux commentaires ;)
2 août 2004 à 16:58
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 ;)
2 août 2004 à 16:52
2 août 2004 à 16:38
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.
2 août 2004 à 16:35
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
2 août 2004 à 16:20
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
2 août 2004 à 16:12
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.
2 août 2004 à 15:41
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 ?
2 août 2004 à 15:16
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
2 août 2004 à 14:45
//1er méthode
echo "Bonjour $ma_var";
?
2 août 2004 à 14:22
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
2 août 2004 à 14:03
<?php
$ma_var = 'tout le monde';
echo 'Bonjour $ma_var';
// affiche Bonjour $ma_var.
echo "Bonjour $ma_var";
// affiche Bonjour tout le monde.
?>
2 août 2004 à 12:05
* 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 ++
2 août 2004 à 11:17
2 août 2004 à 11:14
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
2 août 2004 à 05:18
<?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.
2 août 2004 à 04:42
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 !
1 août 2004 à 02:37
Maintenant je le saurais pour les prochaines fois ...
1 août 2004 à 00:28
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"...
1 août 2004 à 00:00
31 juil. 2004 à 15:38
31 juil. 2004 à 15:29
<?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.
28 juil. 2004 à 22:43
28 juil. 2004 à 10:16
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 :)
27 juil. 2004 à 14:31
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
26 juil. 2004 à 21:50
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 ++
26 juil. 2004 à 18:51
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???
26 juil. 2004 à 15:48
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.
26 juil. 2004 à 14:17
J'suis d'accord... bravo ! très bon post, 10/10
26 juil. 2004 à 12:44
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 !
26 juil. 2004 à 09:52
26 juil. 2004 à 02:23
Inekman.10/10
25 juil. 2004 à 21:13
25 juil. 2004 à 20:49
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.
25 juil. 2004 à 20:37
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
?>