en attendant de purger mes scripts contenant encore des variables globales
j'ai rajouté ceci au début ma librairie principale appelé par toutes mes
pages
[code]
foreach ($_POST as $k => $v) {
if ( (isset($_POST[$k])) && (!isset($$k)) ) {
$$k=$_POST[$k];
}
}
foreach ($_GET as $k => $v) {
if ( (isset($_GET[$k])) && (!isset($$k)) ) {
$$k=$_GET[$k];
}
}
[/code]
en gros ça me recrée les variables envoyés par les formulaires
pour chaque $_GET/POST[nom_variable] il me recrée une variable
$nom_variable
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?
--
Bertrand
Qui trop écoute la météo, passe sa vie au bistrot
(proverbe breton)
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Avec $_POST[mavariable] , tu sais que ta variable provient d'un formulaire ou tout du moins d'un envois POST.
Avec $mavariable, tu n'en sais rien.
Suivant ta façon de développer, cela peut ouvrir le champ à des failles potentielles. Avec les globales désactivées, tu es obligé de vérifier la provenance du contenu de tes variables. Et soit dit en passant, tu es obligé de comprendre les concepts.
Or, la tendance est d'obliger le débutant à comprendre les concepts, et désactiver les globales y contribue.
N'oublions pas que la techno PHP a souffert par le passé d'une image d'amateurisme et de faille de sécurité. Sachant que la plupart de ces failles provenaient de programmations mauvaises et non pas du langage lui même, décision avait été prise de resserrer les boulons.
j'ai loupé un épisode ou bien ?
ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de soucis et de petits malins qui joue avec les url pour tenter de te truander....
Stef
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Avec $_POST[mavariable] , tu sais que ta variable provient d'un formulaire
ou tout du moins d'un envois POST.
Avec $mavariable, tu n'en sais rien.
Suivant ta façon de développer, cela peut ouvrir le champ à des failles
potentielles. Avec les globales désactivées, tu es obligé de vérifier la
provenance du contenu de tes variables. Et soit dit en passant, tu es obligé
de comprendre les concepts.
Or, la tendance est d'obliger le débutant à comprendre les concepts, et
désactiver les globales y contribue.
N'oublions pas que la techno PHP a souffert par le passé d'une image
d'amateurisme et de faille de sécurité. Sachant que la plupart de ces
failles provenaient de programmations mauvaises et non pas du langage lui
même, décision avait été prise de resserrer les boulons.
j'ai loupé un épisode ou bien ?
ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration
par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de
soucis et de petits malins qui joue avec les url pour tenter de te
truander....
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Avec $_POST[mavariable] , tu sais que ta variable provient d'un formulaire ou tout du moins d'un envois POST.
Avec $mavariable, tu n'en sais rien.
Suivant ta façon de développer, cela peut ouvrir le champ à des failles potentielles. Avec les globales désactivées, tu es obligé de vérifier la provenance du contenu de tes variables. Et soit dit en passant, tu es obligé de comprendre les concepts.
Or, la tendance est d'obliger le débutant à comprendre les concepts, et désactiver les globales y contribue.
N'oublions pas que la techno PHP a souffert par le passé d'une image d'amateurisme et de faille de sécurité. Sachant que la plupart de ces failles provenaient de programmations mauvaises et non pas du langage lui même, décision avait été prise de resserrer les boulons.
j'ai loupé un épisode ou bien ?
ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de soucis et de petits malins qui joue avec les url pour tenter de te truander....
Stef
Olivier Miakinen
Bonjour,
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Tout d'abord, je suppose que tu compares $mavariable non pas avec $_POST[mavariable], mais avec $_POST['mavariable'].
Cela étant dit, $mavariable n'est en rien plus dangereux que $_POST['mavariable'], à partir du moment où toutes tes variables sont initialisées avant d'être utilisées. Le danger pourrait venir d'une variable que tu aurais oublié d'initialiser, et qui aurait un effet non prévu au cas où l'initialisation se ferait par une valeur venant de l'extérieur.
Bien entendu, si tu connais ton code par c½ur et que tu as vérifié que chaque variable était bien initialisée, alors il n'y a aucun problème.
D'un autre côté, si tu connais vraiment ton code par c½ur, alors tu devrais savoir quelles sont les variables dont tu as besoin qu'elles soient fournies par l'appelant dans $_POST, et donc tu pourrais te contenter de n'extraire *que* ces variables-là. Le fait que tu veuilles faire une boucle pour extraire tout ce qu'on te passe sans distinction pourrait nous faire douter que tu connaisses ton code si bien que ça, et que tu sois assuré d'avoir vraiment initialisé tout ce qui ne doit pas venir de l'extérieur.
En outre, puisque tu fais une boucle automatique, je ne vois pas bien comment tu peux t'assurer que telle variable est bien un entier compris entre 5 et 20, que telle autre est une chaîne qui ne peut valoir que "admin" ou "guest", que telle autre encore est un chemin d'accès qui pointe bien vers un fichier dans ton répertoire "./images" et pas vers un fichier système à grands coups de "../../../..", etc.
Bref... en résumé, si tu maîtrises ton code, alors ce que tu veux faire n'est peut-être pas dangereux mais il est certainement inutile, tandis que si tu ne maîtrises pas ton code il est potentiellement dangereux.
Bonjour,
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Tout d'abord, je suppose que tu compares $mavariable non pas avec
$_POST[mavariable], mais avec $_POST['mavariable'].
Cela étant dit, $mavariable n'est en rien plus dangereux que
$_POST['mavariable'], à partir du moment où toutes tes variables
sont initialisées avant d'être utilisées. Le danger pourrait venir
d'une variable que tu aurais oublié d'initialiser, et qui aurait un
effet non prévu au cas où l'initialisation se ferait par une valeur
venant de l'extérieur.
Bien entendu, si tu connais ton code par c½ur et que tu as vérifié que
chaque variable était bien initialisée, alors il n'y a aucun problème.
D'un autre côté, si tu connais vraiment ton code par c½ur, alors tu
devrais savoir quelles sont les variables dont tu as besoin qu'elles
soient fournies par l'appelant dans $_POST, et donc tu pourrais te
contenter de n'extraire *que* ces variables-là. Le fait que tu veuilles
faire une boucle pour extraire tout ce qu'on te passe sans distinction
pourrait nous faire douter que tu connaisses ton code si bien que ça, et
que tu sois assuré d'avoir vraiment initialisé tout ce qui ne doit pas
venir de l'extérieur.
En outre, puisque tu fais une boucle automatique, je ne vois pas bien
comment tu peux t'assurer que telle variable est bien un entier compris
entre 5 et 20, que telle autre est une chaîne qui ne peut valoir que
"admin" ou "guest", que telle autre encore est un chemin d'accès qui
pointe bien vers un fichier dans ton répertoire "./images" et pas vers
un fichier système à grands coups de "../../../..", etc.
Bref... en résumé, si tu maîtrises ton code, alors ce que tu veux faire
n'est peut-être pas dangereux mais il est certainement inutile, tandis
que si tu ne maîtrises pas ton code il est potentiellement dangereux.
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Tout d'abord, je suppose que tu compares $mavariable non pas avec $_POST[mavariable], mais avec $_POST['mavariable'].
Cela étant dit, $mavariable n'est en rien plus dangereux que $_POST['mavariable'], à partir du moment où toutes tes variables sont initialisées avant d'être utilisées. Le danger pourrait venir d'une variable que tu aurais oublié d'initialiser, et qui aurait un effet non prévu au cas où l'initialisation se ferait par une valeur venant de l'extérieur.
Bien entendu, si tu connais ton code par c½ur et que tu as vérifié que chaque variable était bien initialisée, alors il n'y a aucun problème.
D'un autre côté, si tu connais vraiment ton code par c½ur, alors tu devrais savoir quelles sont les variables dont tu as besoin qu'elles soient fournies par l'appelant dans $_POST, et donc tu pourrais te contenter de n'extraire *que* ces variables-là. Le fait que tu veuilles faire une boucle pour extraire tout ce qu'on te passe sans distinction pourrait nous faire douter que tu connaisses ton code si bien que ça, et que tu sois assuré d'avoir vraiment initialisé tout ce qui ne doit pas venir de l'extérieur.
En outre, puisque tu fais une boucle automatique, je ne vois pas bien comment tu peux t'assurer que telle variable est bien un entier compris entre 5 et 20, que telle autre est une chaîne qui ne peut valoir que "admin" ou "guest", que telle autre encore est un chemin d'accès qui pointe bien vers un fichier dans ton répertoire "./images" et pas vers un fichier système à grands coups de "../../../..", etc.
Bref... en résumé, si tu maîtrises ton code, alors ce que tu veux faire n'est peut-être pas dangereux mais il est certainement inutile, tandis que si tu ne maîtrises pas ton code il est potentiellement dangereux.
Road2Hells
le26 mars 2007, slambert a dégazé dans fr.comp.lang.php:
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable Avec $_POST[mavariable] , tu sais que ta variable provient d'un
formulaire ou tout du moins d'un envois POST. Avec $mavariable, tu n'en sais rien. oui mais tout dépend ce que tu fais de ta variable derrière
Or, la tendance est d'obliger le débutant à comprendre les concepts, et désactiver les globales y contribue. merci j'aime mieux ton explication que celle qui consiste à dire : "il ne
faut pas" pourquoi ? parce que !
j'ai loupé un épisode ou bien ? ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de soucis et de petits malins qui joue avec les url pour tenter de te truander.... de toutes facons je ne les utilise plus, c'était juste pour mettre vite
fais à jour un code que j'avais pondu il y a longtemps du temps ou c'éatit à On :-)
mais comme quoi, quand c'est bien expliqué, ça va tout de suite mieux !
merci d'avoir perdu du temps pour ma culture générale et darwin ne s'en portera que mieux ;-)
-- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
le26 mars 2007, slambert a dégazé dans fr.comp.lang.php:
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
Avec $_POST[mavariable] , tu sais que ta variable provient d'un
formulaire ou tout du moins d'un envois POST.
Avec $mavariable, tu n'en sais rien.
oui mais tout dépend ce que tu fais de ta variable derrière
Or, la tendance est d'obliger le débutant à comprendre les concepts,
et désactiver les globales y contribue.
merci j'aime mieux ton explication que celle qui consiste à dire : "il ne
faut pas"
pourquoi ?
parce que !
j'ai loupé un épisode ou bien ?
ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la
configuration par défaut, alors c'est que tu es près à assumer ta
responsabilité en cas de soucis et de petits malins qui joue avec les
url pour tenter de te truander....
de toutes facons je ne les utilise plus, c'était juste pour mettre vite
fais à jour un code que j'avais pondu il y a longtemps du temps ou c'éatit
à On :-)
mais comme quoi, quand c'est bien expliqué, ça va tout de suite mieux !
merci d'avoir perdu du temps pour ma culture générale et darwin ne s'en
portera que mieux ;-)
--
Bertrand
Qui trop écoute la météo, passe sa vie au bistrot
(proverbe breton)
le26 mars 2007, slambert a dégazé dans fr.comp.lang.php:
je ne vois pas bien où est le probleme ? en quoi $_POST[mavariable] est moins dangeureux que $mavariable Avec $_POST[mavariable] , tu sais que ta variable provient d'un
formulaire ou tout du moins d'un envois POST. Avec $mavariable, tu n'en sais rien. oui mais tout dépend ce que tu fais de ta variable derrière
Or, la tendance est d'obliger le débutant à comprendre les concepts, et désactiver les globales y contribue. merci j'aime mieux ton explication que celle qui consiste à dire : "il ne
faut pas" pourquoi ? parce que !
j'ai loupé un épisode ou bien ? ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de soucis et de petits malins qui joue avec les url pour tenter de te truander.... de toutes facons je ne les utilise plus, c'était juste pour mettre vite
fais à jour un code que j'avais pondu il y a longtemps du temps ou c'éatit à On :-)
mais comme quoi, quand c'est bien expliqué, ça va tout de suite mieux !
merci d'avoir perdu du temps pour ma culture générale et darwin ne s'en portera que mieux ;-)
-- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
Thierry
"Road2Hells" a écrit dans le message de news:
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?
Regarde : http://www.manuelphp.com/php/security.globals.php et l'exemple court est partlant:
<?php // $authorized = true uniquement si l'utilisateur est identifié if (authenticated_user()) { $authorized = true; }
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière // peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1 // Tout le monde peut facilement être reconnu comme identifié! if ($authorized) { include "/donnees/critiques/data.php"; } ?>
"Road2Hells" <rcageot90_nspm@hotmail.com> a écrit dans le message de news:
Xns98FFCB095EA9Fdowap@212.27.60.37...
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?
Regarde :
http://www.manuelphp.com/php/security.globals.php
et l'exemple court est partlant:
<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière
// peut être définie via register_globals, comme avec l'URL GET
auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?
Regarde : http://www.manuelphp.com/php/security.globals.php et l'exemple court est partlant:
<?php // $authorized = true uniquement si l'utilisateur est identifié if (authenticated_user()) { $authorized = true; }
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière // peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1 // Tout le monde peut facilement être reconnu comme identifié! if ($authorized) { include "/donnees/critiques/data.php"; } ?>
Patrick Mevzek
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros recodée. register_globals et cette dernière n'auraient jamais dû être inventé. Vivement qu'elles disparaissent définitivement, en attendant de faire un pas dans le bon sens c'est à dire l'exact contraire, comme le « taint checking » en Perl.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros recodée.
register_globals et cette dernière n'auraient jamais dû être inventé.
Vivement qu'elles disparaissent définitivement, en attendant de faire un
pas dans le bon sens c'est à dire l'exact contraire, comme le « taint
checking » en Perl.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros recodée. register_globals et cette dernière n'auraient jamais dû être inventé. Vivement qu'elles disparaissent définitivement, en attendant de faire un pas dans le bon sens c'est à dire l'exact contraire, comme le « taint checking » en Perl.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Road2Hells
le28 mars 2007, Patrick Mevzek a dégazé dans fr.comp.lang.php:
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros recodée. register_globals et cette dernière n'auraient jamais dû être inventé. Vivement qu'elles disparaissent définitivement, en attendant de faire un pas dans le bon sens c'est à dire l'exact contraire, comme le « taint checking » en Perl. contrairement à un peu tout ce que j'ai pu lire, je n'ai pas trop peur de
mon code vu que j'ai pris l'habitude en perl d'utiliser "use strict" et par conséquent d'initaliser toutes mes variables par défaut. Ce qui fait que mes programmes en php utilisent les mêmes principes.
le fait d'avoir ajouté le && (!isset à chaque fois me permet aussi d'éviter d'écraser une variable non prévu dans le formulaire !
m'enfin ensuite tout n'est qu'une histoire d'appréciation personnelle.
merci pour toutes ces réponses constructives qui m'ont en fait rassuré :-) -- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
le28 mars 2007, Patrick Mevzek a dégazé dans fr.comp.lang.php:
y a t'il un autre moyen lorsque les variables globales sont à OFF
dans le php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros
recodée. register_globals et cette dernière n'auraient jamais dû être
inventé. Vivement qu'elles disparaissent définitivement, en attendant
de faire un pas dans le bon sens c'est à dire l'exact contraire, comme
le « taint checking » en Perl.
contrairement à un peu tout ce que j'ai pu lire, je n'ai pas trop peur de
mon code vu que j'ai pris l'habitude en perl d'utiliser "use strict" et
par conséquent d'initaliser toutes mes variables par défaut.
Ce qui fait que mes programmes en php utilisent les mêmes principes.
le fait d'avoir ajouté le && (!isset à chaque fois me permet aussi d'éviter
d'écraser une variable non prévu dans le formulaire !
m'enfin ensuite tout n'est qu'une histoire d'appréciation personnelle.
merci pour toutes ces réponses constructives qui m'ont en fait rassuré :-)
--
Bertrand
Qui trop écoute la météo, passe sa vie au bistrot
(proverbe breton)
le28 mars 2007, Patrick Mevzek a dégazé dans fr.comp.lang.php:
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le php.ini?
Oui, l'horreur import_request_variables() que vous avez en gros recodée. register_globals et cette dernière n'auraient jamais dû être inventé. Vivement qu'elles disparaissent définitivement, en attendant de faire un pas dans le bon sens c'est à dire l'exact contraire, comme le « taint checking » en Perl. contrairement à un peu tout ce que j'ai pu lire, je n'ai pas trop peur de
mon code vu que j'ai pris l'habitude en perl d'utiliser "use strict" et par conséquent d'initaliser toutes mes variables par défaut. Ce qui fait que mes programmes en php utilisent les mêmes principes.
le fait d'avoir ajouté le && (!isset à chaque fois me permet aussi d'éviter d'écraser une variable non prévu dans le formulaire !
m'enfin ensuite tout n'est qu'une histoire d'appréciation personnelle.
merci pour toutes ces réponses constructives qui m'ont en fait rassuré :-) -- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
Road2Hells
le28 mars 2007, Thierry a dégazé dans fr.comp.lang.php:
"Road2Hells" a écrit dans le message de news:
en quoi $_POST[mavariable] est moins dangeureux que $mavariable j'ai loupé un épisode ou bien ? Regarde :
http://www.manuelphp.com/php/security.globals.php et l'exemple court est partlant: <?php // $authorized = true uniquement si l'utilisateur est identifié if (authenticated_user()) { $authorized = true; }
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière // peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1 // Tout le monde peut facilement être reconnu comme identifié! if ($authorized) { include "/donnees/critiques/data.php"; } ?> ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict m'a obligé à prendre l'habitude de déclarer toutes mes variables en début de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
donc l'utilisation en plus du (!isset($variable)) évite l'écrasement accidentel
-- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
le28 mars 2007, Thierry a dégazé dans fr.comp.lang.php:
"Road2Hells" <rcageot90_nspm@hotmail.com> a écrit dans le message de
news: Xns98FFCB095EA9Fdowap@212.27.60.37...
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?
Regarde :
http://www.manuelphp.com/php/security.globals.php
et l'exemple court est partlant:
<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}
// Comme nous n'avons pas initialisé $authorized avec false, cette
dernière // peut être définie via register_globals, comme avec l'URL
GET auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>
ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict
m'a obligé à prendre l'habitude de déclarer toutes mes variables en début
de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
donc l'utilisation en plus du (!isset($variable)) évite l'écrasement
accidentel
--
Bertrand
Qui trop écoute la météo, passe sa vie au bistrot
(proverbe breton)
le28 mars 2007, Thierry a dégazé dans fr.comp.lang.php:
"Road2Hells" a écrit dans le message de news:
en quoi $_POST[mavariable] est moins dangeureux que $mavariable j'ai loupé un épisode ou bien ? Regarde :
http://www.manuelphp.com/php/security.globals.php et l'exemple court est partlant: <?php // $authorized = true uniquement si l'utilisateur est identifié if (authenticated_user()) { $authorized = true; }
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière // peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1 // Tout le monde peut facilement être reconnu comme identifié! if ($authorized) { include "/donnees/critiques/data.php"; } ?> ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict m'a obligé à prendre l'habitude de déclarer toutes mes variables en début de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
donc l'utilisation en plus du (!isset($variable)) évite l'écrasement accidentel
-- Bertrand Qui trop écoute la météo, passe sa vie au bistrot (proverbe breton)
slambert
ok mais comme répondu dans un autre message, mon passage en premier lieu par le language perl et l'utilisation du langage perl avec le use strict m'a obligé à prendre l'habitude de déclarer toutes mes variables en début de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
C'est pas mal, ca.
Bon bien sur, on en est pas à typer les fonctions/variables et à tout déclarer en début de script.
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela : toutes les variables utilisées dans le script se retrouveraient initilaisées à vide en début de script, et il n'y aurait plus qu'à passer derrière pour supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Un IDE propose t il cette option/gadget à ce jour ?
Stef
ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict
m'a obligé à prendre l'habitude de déclarer toutes mes variables en début
de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
C'est pas mal, ca.
Bon bien sur, on en est pas à typer les fonctions/variables et à tout
déclarer en début de script.
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela :
toutes les variables utilisées dans le script se retrouveraient initilaisées
à vide en début de script, et il n'y aurait plus qu'à passer derrière pour
supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Un IDE propose t il cette option/gadget à ce jour ?
ok mais comme répondu dans un autre message, mon passage en premier lieu par le language perl et l'utilisation du langage perl avec le use strict m'a obligé à prendre l'habitude de déclarer toutes mes variables en début de programme avec les valeurs par défaut à "off" ou "no" ou "-1"
C'est pas mal, ca.
Bon bien sur, on en est pas à typer les fonctions/variables et à tout déclarer en début de script.
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela : toutes les variables utilisées dans le script se retrouveraient initilaisées à vide en début de script, et il n'y aurait plus qu'à passer derrière pour supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Un IDE propose t il cette option/gadget à ce jour ?
Stef
Olivier Miakinen
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela : toutes les variables utilisées dans le script se retrouveraient initialisées à vide en début de script, et il n'y aurait plus qu'à passer derrière pour supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à cause des « variables variables ».
Un IDE propose t il cette option/gadget à ce jour ?
Je passe.
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela :
toutes les variables utilisées dans le script se retrouveraient initialisées
à vide en début de script, et il n'y aurait plus qu'à passer derrière pour
supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à
cause des « variables variables ».
Un IDE propose t il cette option/gadget à ce jour ?
Il faudrait presque une option dans l'IDE qui permette d'automatiser cela : toutes les variables utilisées dans le script se retrouveraient initialisées à vide en début de script, et il n'y aurait plus qu'à passer derrière pour supprimer sauvagement les lignes des variables post/get/cookie utilisées.
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à cause des « variables variables ».
Un IDE propose t il cette option/gadget à ce jour ?
Je passe.
slambert
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à cause des « variables variables ».
Très bonne remarque.
Un IDE propose t il cette option/gadget à ce jour ? Je passe.
Mais si voyons !
Je dis dans le micro a l'IDE : Sort moi les variables ne venant pas du web et fait un unset() dessus en début de script. Et puis après, l'intelligence artificielle du Zend framework, elle appelle ses petites marmottes internes et toutes les variables sont bien placées en tête de script, avec l'indentation, les commentaires... C'est que c'est intelligent, une marmotte....
Bon ok, => []
Dzlé
N'empêche, on rigole, mais quand tu vois des trucs comme Celine de N. Ruiz, un jour, ça se passera peut être comme cela.
Stef
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à
cause des « variables variables ».
Très bonne remarque.
Un IDE propose t il cette option/gadget à ce jour ?
Je passe.
Mais si voyons !
Je dis dans le micro a l'IDE : Sort moi les variables ne venant pas du web
et fait un unset() dessus en début de script. Et puis après, l'intelligence
artificielle du Zend framework, elle appelle ses petites marmottes internes
et toutes les variables sont bien placées en tête de script, avec
l'indentation, les commentaires... C'est que c'est intelligent, une
marmotte....
Bon ok, => []
Dzlé
N'empêche, on rigole, mais quand tu vois des trucs comme Celine de N. Ruiz,
un jour, ça se passera peut être comme cela.
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à cause des « variables variables ».
Très bonne remarque.
Un IDE propose t il cette option/gadget à ce jour ? Je passe.
Mais si voyons !
Je dis dans le micro a l'IDE : Sort moi les variables ne venant pas du web et fait un unset() dessus en début de script. Et puis après, l'intelligence artificielle du Zend framework, elle appelle ses petites marmottes internes et toutes les variables sont bien placées en tête de script, avec l'indentation, les commentaires... C'est que c'est intelligent, une marmotte....
Bon ok, => []
Dzlé
N'empêche, on rigole, mais quand tu vois des trucs comme Celine de N. Ruiz, un jour, ça se passera peut être comme cela.
