Bonjour,
connaissez-vous une façon de simplifier cette écriture PHP ?
Moi je la trouve très bien cette cette ligne pour tester et affecter ,,.
Mais bon, si tu veux à tout prix en passer par une fonction....
évidemment ! Je n'y avais pas pensé !
Merci No6 !
T'a essayé avec la façon "Macro" ??
Je serai curieux de savoir si cela fonctionne réellement .... ???
Ah, je n'avais pas vu la deuxième partie de ton message... (tu devais être en train d'éditer)
J'avoue que... je me perds un peu avec ces macros... ! Tu m'apprends déjà que ça existe. Il faudrait que je me penche plus dessus.
Non, les macros n'existent pas véritablement sous PHP
C'est juste une utilisation peu orthodoxe de la syntaxe" define "
ex :
define("C_Hello", "Bonjour le monde.");
...
echo C_Hello; // affiche "Bonjour le monde."
mais qui est ici transformée par :
define('HeurePrésente', 'time()');
...
echo HeurePrésente; // affiche l'heure... ou ce code s'éxécute
Donc en extrapolant, on peut y mettre une fonction un peu plus élaborée.
L’intérêt c'est que lors de l’exécution du code PHP, au lieu de gérer l’appel d'une fonction et remplir une pile d'appel avec les arguments ( qui derrière régénéré d'autres appels pour la fonction isset ), l'interprétateur PHP fait juste une substitution de code sur la pseudo constante, ce qui permet d'économiser un peu(?) de temps CPU, dans l'exécution du code.
Dans tous les Langages, en principe, l'appel d'une fonction implique une recopie de la fonction dans une partie mémoire de l'interpréteur pour réaliser son exécution et des tas d'autre trucs comme des questions de bac à sable; ce qui au final pour ue fonction relativement simple mais pouvant être appelée fréquemment dans le code, on peut en arriver à avoir un effondrement des performances.
Ne pas oublier qu'on est sur du web, et qu'il peut y avoir des pics avec des millions d'utilisateurs à remplir un petit formulaire innocent, qui finissent par déborder la capacité de réponse des serveurs, et ou souvent un code mal optimisé peut devenir un vrai cauchemars.
ben... j'ai cru que ça marchait quand j'ai utilisé leur formule
Ah oui, effectivement, ça va pas...
Je vais faire mes tests à un moment ou un autre..
J'ai aussi cru comprendre que ça ne pouvait marcher qu'a partir de PHP5...
Je ferai mes essais sur différentes version (via docker) mais tout de suite tout de suite...
Cette histoire de pseudo-macro m'intrigue...
c'était quand même un truc cool du langage C, je sais pas pourquoi les langages actuels n'ont pas repris cette feature...
Bon, j'ai fait des tests, et OK, il n'y a pas de pseudo-macro en PHP.
j'ai même repris le temps de relire tout l'article sur BYTES, et j'avais bien lu de travers....
pour conclure, je pense adopter la syntaxe suivante :
merci pour toutes vos réponses. Très instructif.
Jusqu'à quel point, pensez-vous qu'une telle fonction est un handicap sur le temps d'exécution ?
Et pourquoi cela changerait quelque chose... Je ne comprends pas bien... Le but d'une fonction, n'est-il pas de condenser le code et d'éviter la redondance ?
Et enfin, quels outils utilisez-vous pour voir ces temps d'exécution ? Ceux de Firefox ? J'en ai bien vu ici ou là, mais cela m'a vite découragé quand j'ai cherché comment spécifiquement cibler une partie de code... Par où commencer quand on souhaite étudier ce genre d'outils d'analyse ?
merci encore...
D’abord, ici, on parle de temps d''exécution coté serveur, sollicité par l'interpréteur PHP.
Ensuite il ne s'agit pas forcément d'avoir le code super optimisé partout, on regarde surtout les temps de réponse du serveur pour chaque requête (ou demande de page à composer en PHP, dans ton cas).
Bien sur, plus il y a de requêtes, plus le serveur est sollicité.
Entre le moment ou 1 internaute demande une nouvelle page PHP et celle ou il reçois sa réponse, le serveur peut très bien avoir reçu '10.000" demandes faites par d'autres internautes juste avant, et l'internaute devra "sagement" attendre son tour avant d'avoir une réponse.
Plus chaque réponse précédente prendra du temps, et plus cela s'accumulera dans un retard qui ne fera que croître, jusqu’à en saturer le serveur qui peut alors "tomber" (ou plutôt devenant incapable de répondre), parce que sa pile d'appel a "explosé".
La première stratégie dans ce cas la, c'est de créer des caches de pages toutes faites correspondants au requêtes les plus fréquentes et éviter ainsi au serveur de perdre son temps cpu à refaire 100 fois les mêmes préparations de pages.
Il y a d'autres techniques comme le Load-balancing, mais ça, c'est plus une solution hardware, et ça coûte un peu plus cher ( et c'est un peu débile de l'utiliser sur du code non optimisé, avant).
Mais dans le cas d'une requête contenant des variables envoyées par un internaute (un formulaire par exemple) comme elles sont imprévisibles par nature, le coup du cache ne pourra pas s'appliquer, et on est bien obligé de bouffer la cpu du serveur.
D’où l'idée d"éviter de rajouter une fonction qui esthétise le code mais qui rajoute quelques octets au code et quelques millièmes de secondes en temps d’exécution.
Car la, chaque millième de seconde économisé est une "victoire".
L'esthétique du code passe largement en second plan.
Bon, comme j'ai fait quelques années d'assembleur, et j'ai une idée assez précise de ce qui se passe entre l'écriture dune ligne de code en langage évolué (comme le PHP) et la façon dont elle est traduite en code machine pour être exécutée, de ce qu'est réellement une pile d'appel, et des tas d'autres trucs que seuls quelques ingénieurs connaissent et dont les "nouveaux programmeurs" n'ont pas à se farcir la tête pour faire leur job.
Si tu veux te faire une idée, il y a peut être des trucs instructifs et récréatif à faire autour des https://fr.wikipedia.org/wiki/Fab_lab, ou à moment ou un autre tu sera amené à faire du https://fr.wikipedia.org/wiki/Forth_(langage), pour lequel j'ai toujours eu un petit faible
Bien sur on n'a pas forcément le besoin impératif de créer du code super optimisé pour tous les sites du monde, avec 440.000.000 de visites chaque mois, par exemple.. (Wikipédia, et le chiffre ne concerne que les visites et mon le nombre de pages vues), mais perso, je pense que c'est une bonne chose de savoir que le problème des temps de réponses peut devenir hyper-prioritaire subitement; et la, dommage si le site est écrit avec les pieds, parce que le serveur va faire des chutes à répétitions, tant que le code ne sera pas "remis au carré".
C'est déjà arrivé, et ça arrivera encore; par exemple sur un blog innocent qui devient tout à coup le "centre du monde" pour une simple photo devenant célèbre... (puis retombé dans l'oubli au bout d'une semaine).
J'ai fait pas mal de TMA dans ma vie de codeur, et je peux te dire que le code esthétique, c'est loin d'être ma tasse de thé.
Ce que j'ai apprécié le plus quand je devais me plonger dans le code des autres, c'est d'y trouver des commentaires utiles et explicatifs.
Le top, c'est d'y retrouver aussi un peu d'humour (mais pas trop, et toujours lié à une compréhension du code), ce qui est pour moi la marque des très grands codeurs.
Faire du code propre, c'est avant tout respecter des règles d'écriture, avoir des noms de variables clairs, etc...
Pour les commentaires , ma méthode c'est d'expliquer le but, la méthode employée, les acteurs, et la trame des événements à suivre, un peu comme une pièce de théâtre, mais je ne fais pas ça partout, juste pour les trucs un peu compliqués à coder, avec des concepts incompréhensibles pour les informaticiens, comme j'en ai rencontré dans l'univers de la comptabilité sur la "haute finance".
wow... ça, c'est une réponse écrit avec le coeur ! ^^
Je te remercie, mais je ne sais pas si j'étais digne de recevoir une réponse aussi complète, vu que... je code essentiellement pour moi-même et le plaisir (je me fais mes propres petites appli avec ce que je sais... une petite appli pour faire ma propre compta... Cela reste souvent en local, ou de toute manière, pas destiné à des centaines de milliers d'utilisateur... ! (peut-être un jour je me lancerai dans quelque chose de concurrent à facebook... mais cela me semble lointain ! ^^)
Ceci dit, je comprends mieux la problématique. Je ne pensais pas que l'écriture de fonctions pouvait impacter l'exécution du code de la sorte (j'imagine que cela dépend du type de fonction aussi). Donc, ces nouvelles techniques qui demandent de mettre tout en classes (par exemple la PDO pour l'exécution de requêtes variées vers une base de donnée) n'a pas que des bons côtés, si je comprends bien... ?
On en apprend tous les jours...
Heu, la programmation [orienté] Objet (POO), et l’utilisation de la PDO, ce sont 2 choses différentes.
La PDO est certes basée sur la POO, mais pour profiter de cette technique et permettre d’avoir une vraie indépendance vis à vis des bases de Données.
On est quand même dans un problématique N-tiers, et l’idée de pouvoir changer de « marque » de données pour une autre est un atout indéniable.
De reste, l’exécution du code PDO est éxécuté sur le serveur de la base de données, et les histoires de performances coté serveur SGBD ne concernent pas le problématiques PHP (ou autre langage) qui elles tournent sur leur serveur Appache (ou Ngnix, ou…? )
Quand à la programmation Objet en elle même elle est censée simplifier les questions sur le parallélisme, et donc améliorer les performances ; mais c’est une autre paire de manches dans la réalité.
Sans perdre de de vue que la POO permet de maîtriser les "monstres" de codes; sans POO, Mac OS X ou W10 ne pourraient être écrits, pour ne citer que les plus visibles.
L’industrie du Spatial utilise aussi de la POO (ADA) => http://www.touilleur-express.fr/2012/06/30/usi2012-quel-logiciel-y-a-t-il-dans-une-fusee-ariane-5/
En matière d'optimisation de code il ne faut pas oublier les triggers dans les bases de données, ni la possibilité de grouper des requêtes pour ne faire qu'un seul appel au serveur de base de données (insertions/updates multiples par exemple).
Exemple fictif :
Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)