LES RÈGLES DE LA BONNE PROGRAMMATION EN PHP

Signaler
Messages postés
163
Date d'inscription
lundi 29 septembre 2003
Statut
Membre
Dernière intervention
8 mai 2010
-
Messages postés
164
Date d'inscription
jeudi 23 octobre 2003
Statut
Membre
Dernière intervention
25 août 2008
-
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

Messages postés
164
Date d'inscription
jeudi 23 octobre 2003
Statut
Membre
Dernière intervention
25 août 2008

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.
Messages postés
1662
Date d'inscription
lundi 16 septembre 2002
Statut
Membre
Dernière intervention
30 juillet 2008
1
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.
Messages postés
11
Date d'inscription
lundi 15 juillet 2002
Statut
Membre
Dernière intervention
2 janvier 2008

"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
Messages postés
488
Date d'inscription
samedi 5 avril 2003
Statut
Membre
Dernière intervention
31 mars 2009
4
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.
Afficher les 100 commentaires