Verifier la coherence des inclusions dans un gros projet
5 réponses
Harry Cover
Bonjour à tous,
Je bosse sur un projet perso assez conséquent en php, avec plus de 40
fichiers source, des templates, des images, etc...
Je n'ai pas envie de vérifier que toutes les fonctions sont
correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Du coup, je me demande s'il n'y a pas un script ou un programme
capable de faire cela à ma place.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jedi121
Harry Cover a écrit le 23/02/2004 :
Bonjour à tous,
Je bosse sur un projet perso assez conséquent en php, avec plus de 40 fichiers source, des templates, des images, etc...
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des instructions include adéquates. Du coup, je me demande s'il n'y a pas un script ou un programme capable de faire cela à ma place.
Est ce que vous avez une soluce pour moi ? ;)
On doit pouvoir y voir plus clair avec le code nommé *phphelpme* proposé plus bas dans ce NG. Voir http://steph.pineau.free.fr/php/index.php
Harry Cover a écrit le 23/02/2004 :
Bonjour à tous,
Je bosse sur un projet perso assez conséquent en php, avec plus de 40
fichiers source, des templates, des images, etc...
Je n'ai pas envie de vérifier que toutes les fonctions sont
correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Du coup, je me demande s'il n'y a pas un script ou un programme
capable de faire cela à ma place.
Est ce que vous avez une soluce pour moi ? ;)
On doit pouvoir y voir plus clair avec le code nommé *phphelpme*
proposé plus bas dans ce NG.
Voir http://steph.pineau.free.fr/php/index.php
Je bosse sur un projet perso assez conséquent en php, avec plus de 40 fichiers source, des templates, des images, etc...
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des instructions include adéquates. Du coup, je me demande s'il n'y a pas un script ou un programme capable de faire cela à ma place.
Est ce que vous avez une soluce pour moi ? ;)
On doit pouvoir y voir plus clair avec le code nommé *phphelpme* proposé plus bas dans ce NG. Voir http://steph.pineau.free.fr/php/index.php
Jean-Marc Molina
Bonjour Harry,
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non déclarée » ? Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de bien concevoir et développer ton projet pour éviter des problèmes.
À toi de déterminer dans quel cas ces problèmes pourraient arriver et de trouver les solutions adéquates pour les résoudre. Je pense par exemple à une fonction dont la liste des paramètres a été modifiée mais dont les appels n'ont pas été mis à jour...
À mes débuts en PHP je cherchais une solution équivalente et la seule solution que j'avais trouvée était d'utiliser la commande « php -f mon_script.php ». Ça fonctionne la syntaxe du fichier en le parsant. Donc d'include en include il peut t'indiquer des erreurs. J'avais demandé à ce que cette fonctionnalité soit ajoutée à Zend Studio que je pensais acheté mais finalement ça n'est jamais arrivé, peut-être qu'on peut trouver ça dans un outil équivalent.
La solution que j'ai adoptée c'est d'avoir une meilleure conception au bénéfice d'un développement moins incertain.
Sinon pour modéliser la « cohérence » de tes inclusions je te conseille de faire un graphe UML, équivalent à un plan de site où on montre les liens entres les pages HTML, les scripts JavaScript, les images, etc...
JM
Bonjour Harry,
Je n'ai pas envie de vérifier que toutes les fonctions sont
correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non
déclarée » ?
Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de
bien concevoir et développer ton projet pour éviter des problèmes.
À toi de déterminer dans quel cas ces problèmes pourraient arriver et de
trouver les solutions adéquates pour les résoudre. Je pense par exemple à
une fonction dont la liste des paramètres a été modifiée mais dont les
appels n'ont pas été mis à jour...
À mes débuts en PHP je cherchais une solution équivalente et la seule
solution que j'avais trouvée était d'utiliser la commande « php -f
mon_script.php ». Ça fonctionne la syntaxe du fichier en le parsant. Donc
d'include en include il peut t'indiquer des erreurs. J'avais demandé à ce
que cette fonctionnalité soit ajoutée à Zend Studio que je pensais acheté
mais finalement ça n'est jamais arrivé, peut-être qu'on peut trouver ça dans
un outil équivalent.
La solution que j'ai adoptée c'est d'avoir une meilleure conception au
bénéfice d'un développement moins incertain.
Sinon pour modéliser la « cohérence » de tes inclusions je te conseille de
faire un graphe UML, équivalent à un plan de site où on montre les liens
entres les pages HTML, les scripts JavaScript, les images, etc...
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non déclarée » ? Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de bien concevoir et développer ton projet pour éviter des problèmes.
À toi de déterminer dans quel cas ces problèmes pourraient arriver et de trouver les solutions adéquates pour les résoudre. Je pense par exemple à une fonction dont la liste des paramètres a été modifiée mais dont les appels n'ont pas été mis à jour...
À mes débuts en PHP je cherchais une solution équivalente et la seule solution que j'avais trouvée était d'utiliser la commande « php -f mon_script.php ». Ça fonctionne la syntaxe du fichier en le parsant. Donc d'include en include il peut t'indiquer des erreurs. J'avais demandé à ce que cette fonctionnalité soit ajoutée à Zend Studio que je pensais acheté mais finalement ça n'est jamais arrivé, peut-être qu'on peut trouver ça dans un outil équivalent.
La solution que j'ai adoptée c'est d'avoir une meilleure conception au bénéfice d'un développement moins incertain.
Sinon pour modéliser la « cohérence » de tes inclusions je te conseille de faire un graphe UML, équivalent à un plan de site où on montre les liens entres les pages HTML, les scripts JavaScript, les images, etc...
JM
Harry Cover
On 24 Feb 2004 13:11:09 GMT, Jean-Marc Molina wrote:
Bonjour Harry,
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non déclarée » ? Ou les double include_once, etc...
Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de bien concevoir et développer ton projet pour éviter des problèmes. Ouarf, ouarf.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui font plus de 3 Mo en taille, ou tout a été écrit par des personnes différentes, sans documentation (ou presque). Je cherche à reconstituer une doc sans trop suer (ou le moins possible).
La solution que j'ai adoptée c'est d'avoir une meilleure conception au bénéfice d'un développement moins incertain. Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
On 24 Feb 2004 13:11:09 GMT, Jean-Marc Molina
<goa_pasdepourriel_@ifrance.com> wrote:
Bonjour Harry,
Je n'ai pas envie de vérifier que toutes les fonctions sont
correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non
déclarée » ?
Ou les double include_once, etc...
Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de
bien concevoir et développer ton projet pour éviter des problèmes.
Ouarf, ouarf.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui
font plus de 3 Mo en taille, ou tout a été écrit par des personnes
différentes, sans documentation (ou presque).
Je cherche à reconstituer une doc sans trop suer (ou le moins
possible).
La solution que j'ai adoptée c'est d'avoir une meilleure conception au
bénéfice d'un développement moins incertain.
Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
On 24 Feb 2004 13:11:09 GMT, Jean-Marc Molina wrote:
Bonjour Harry,
Je n'ai pas envie de vérifier que toutes les fonctions sont correctement déclarées dans chaque fichier source à l'aide des
instructions include adéquates.
Tu veux vérifier ça pour t'éviter des bogues du genre « fonction non déclarée » ? Ou les double include_once, etc...
Il faudrait savoir « pourquoi » ça devrait se produire. C'est aussi à toi de bien concevoir et développer ton projet pour éviter des problèmes. Ouarf, ouarf.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui font plus de 3 Mo en taille, ou tout a été écrit par des personnes différentes, sans documentation (ou presque). Je cherche à reconstituer une doc sans trop suer (ou le moins possible).
La solution que j'ai adoptée c'est d'avoir une meilleure conception au bénéfice d'un développement moins incertain. Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
Jean-Marc Molina
Ou les double include_once, etc...
Déjà en utilisant un système de facades tu simplifieras les sources. Les scripts incluent un seul et même include qui se charge lui-même d'inclure les autres. Après tu peux optimiser et découper ton projet en module, chaque module ayant sa propre facade.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui font plus de 3 Mo en taille, ou tout a été écrit par des personnes
différentes, sans documentation (ou presque).
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur des petits projets. Après recherche mon plus gros source (on était plusieurs sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code ! Donc 3 Mo... Ya comme un problème :D.
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil Doxygen pour générer la doc à partir de là. Pour le travail en équipe il existe CVS et des clients (WinCVS sous Windows).
Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
Moi je te conseille de découper ce projet en module, de créer plusieurs sources, d'utiliser un seul include au départ et d'optimiser ensuite. Si vous utilisez une techno comme Zend au niveau du serveur la perte en perf est ridicule puisque les sources sont compilés. Déjà avec un bon graphe de qui a besoin de qui, tu devrais y voir plus clair.
Amuse-toi bien ^^ JM
Ou les double include_once, etc...
Déjà en utilisant un système de facades tu simplifieras les sources.
Les scripts incluent un seul et même include qui se charge lui-même
d'inclure les autres. Après tu peux optimiser et découper ton projet en
module, chaque module ayant sa propre facade.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui
font plus de 3 Mo en taille, ou tout a été écrit par des personnes
différentes, sans documentation (ou presque).
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie
de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur
des petits projets. Après recherche mon plus gros source (on était plusieurs
sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code !
Donc 3 Mo... Ya comme un problème :D.
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil
Doxygen pour générer la doc à partir de là. Pour le travail en équipe il
existe CVS et des clients (WinCVS sous Windows).
Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
Moi je te conseille de découper ce projet en module, de créer plusieurs
sources, d'utiliser un seul include au départ et d'optimiser ensuite. Si
vous utilisez une techno comme Zend au niveau du serveur la perte en perf
est ridicule puisque les sources sont compilés. Déjà avec un bon graphe de
qui a besoin de qui, tu devrais y voir plus clair.
Déjà en utilisant un système de facades tu simplifieras les sources. Les scripts incluent un seul et même include qui se charge lui-même d'inclure les autres. Après tu peux optimiser et découper ton projet en module, chaque module ayant sa propre facade.
Evidemment tu as raison, mais vois-tu, je bosse sur des sources qui font plus de 3 Mo en taille, ou tout a été écrit par des personnes
différentes, sans documentation (ou presque).
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur des petits projets. Après recherche mon plus gros source (on était plusieurs sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code ! Donc 3 Mo... Ya comme un problème :D.
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil Doxygen pour générer la doc à partir de là. Pour le travail en équipe il existe CVS et des clients (WinCVS sous Windows).
Idem qu'au dessus. Je n'ai pas participé à la structuration du code.
Moi je te conseille de découper ce projet en module, de créer plusieurs sources, d'utiliser un seul include au départ et d'optimiser ensuite. Si vous utilisez une techno comme Zend au niveau du serveur la perte en perf est ridicule puisque les sources sont compilés. Déjà avec un bon graphe de qui a besoin de qui, tu devrais y voir plus clair.
Amuse-toi bien ^^ JM
Harry Cover
On 25 Feb 2004 10:32:48 GMT, "Jean-Marc Molina" wrote:
Ou les double include_once, etc...
Déjà en utilisant un système de facades tu simplifieras les sources. Les scripts incluent un seul et même include qui se charge lui-même d'inclure les autres. Après tu peux optimiser et découper ton projet en module, chaque module ayant sa propre facade. Forcément, c'est pas bête. Je note ca sur la fiche d'intentions.
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur des petits projets. Après recherche mon plus gros source (on était plusieurs sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code ! Donc 3 Mo... Ya comme un problème :D. Aucun problème :) C'est juste un projet abouti et assez complet.
Je vois pas en quoi cela te choque...
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil Doxygen pour générer la doc à partir de là. Pour le travail en équipe il existe CVS et des clients (WinCVS sous Windows). Ok. Pas bête ;)
On 25 Feb 2004 10:32:48 GMT, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:
Ou les double include_once, etc...
Déjà en utilisant un système de facades tu simplifieras les sources.
Les scripts incluent un seul et même include qui se charge lui-même
d'inclure les autres. Après tu peux optimiser et découper ton projet en
module, chaque module ayant sa propre facade.
Forcément, c'est pas bête. Je note ca sur la fiche d'intentions.
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie
de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur
des petits projets. Après recherche mon plus gros source (on était plusieurs
sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code !
Donc 3 Mo... Ya comme un problème :D.
Aucun problème :) C'est juste un projet abouti et assez complet.
Je vois pas en quoi cela te choque...
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil
Doxygen pour générer la doc à partir de là. Pour le travail en équipe il
existe CVS et des clients (WinCVS sous Windows).
Ok. Pas bête ;)
On 25 Feb 2004 10:32:48 GMT, "Jean-Marc Molina" wrote:
Ou les double include_once, etc...
Déjà en utilisant un système de facades tu simplifieras les sources. Les scripts incluent un seul et même include qui se charge lui-même d'inclure les autres. Après tu peux optimiser et découper ton projet en module, chaque module ayant sa propre facade. Forcément, c'est pas bête. Je note ca sur la fiche d'intentions.
Il faudrait en effet revoir tout de A à Z car un source de 3 Mo dans ma vie de développeur j'en ai jamais vu ! Et pourtant je n'ai pas travaillé que sur des petits projets. Après recherche mon plus gros source (on était plusieurs sur le coup ^^) fait 257 Ko, c'était en C et il y a 8,000 lignes de code ! Donc 3 Mo... Ya comme un problème :D. Aucun problème :) C'est juste un projet abouti et assez complet.
Je vois pas en quoi cela te choque...
Pour la documentation je te conseille d'utiliser les tags JavaDoc et l'outil Doxygen pour générer la doc à partir de là. Pour le travail en équipe il existe CVS et des clients (WinCVS sous Windows). Ok. Pas bête ;)
