Bonne pratique : tester la présence de clé dans un tableau

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Bonne pratique : tester la présence de clé dans un tableau

Re: Bonne pratique : tester la présence de clé dans un table

par moogli » 24 avr. 2013, 20:15

salut,

oui c'est utile simplement pour avoir une valeur par défaut.
ensuite rien pour éviter d'avoir un code foireux basé sur une possibilité qui changera peux être ou que tu ne pourra maîtriser le jour où l'on te demandera de modifier le code ;)

ceci est d'autant plus vrai que les valeur issus des utilisateurs (get, post, cookie) ou d'autre application.

bref ne jamais présumer d'un truc c'est le meilleur moyen d'éviter une connerie :)

@+

Re: Bonne pratique : tester la présence de clé dans un table

par janoyolo » 24 avr. 2013, 11:18

Merci pour vos réponses mais j'aurais aimé avoir une réflexion sur la nécessité "absolue" ou non de tester la présence des clés dans un tableau lorsqu'il s'agit de faire un concaténation ou lorsqu'il s'agit d'utiliser la valeur de cette clé en tant que 'string'. Si la clé n'est pas systématiquement présente et qu'au niveau du code, c'est géré (par exemple par l'affichage d'une chaîne vide), utiliser les ressources du serveur pour "tester" la présence de cette clé est-il vraiment utile ?

Re: Bonne pratique : tester la présence de clé dans un table

par sirakawa » 23 avr. 2013, 20:16

Pour ce que je programme, moi, le test de présence est indispensable:
ce sont des tableaux de propriétés grammaticales (genre, nombre, nature...) dont certaines n'existent pas toujours (une préposition n'a pas de genre).
J'utilise deux méthodes:
forcer les propriétés sans objet à "" (pas à NULL) lors de l'insertion dans la BDD.
tester systématiquement les tableaux résultants avec isset (au cas où j'aurais oublié un cas particulier)
$val = (isset($tableau[$i]= ? $tableau[$i]: "";
$phrase .= $val;
//ou
$phrase = (isset($tableau[$i]= ? $phrase.$tableau[$i]: "";
Il me semble possible, si les notices remontées permettent d'identifier le développeur, de lui retourner une consigne de modification inspirée du code ci-dessus qui ne change que peu de choses, et d'ajouter cette consigne pour l'avenir.

Re: Bonne pratique : tester la présence de clé dans un table

par Mazarini » 23 avr. 2013, 13:34

A mes yeux, l’intérêt de supprimer les notices c'est de mettre en évidence les fautes de frappe dans les noms de variable.

Bonne pratique : tester la présence de clé dans un tableau

par janoyolo » 23 avr. 2013, 11:46

Bonjour,

J'aurais besoin de vos lumières concernant les bonnes pratiques à mettre en place sur un projet PHP déjà existant.

Aujourd'hui, un grand nombre de notices sont remontées sur nos environnements de DEV car certains développeurs ne testent pas la présence des offset dans un tableau avant d'y faire référence.

ex. 1 :
$strMaVariable = 'Ma phrase : '.$aMonArray[0];
J'aurais tendance à tester la présence de l'offset avant de l'utiliser.

ex. 2 :
$strMaVariable = 'Ma phrase : '.array_key_exists(0, $aMonArray)?$aMonArray[0]:'';
Cependant, vu l'ampleur de l'utilisation des array dans notre projet (ainsi que le nombre de notice relevées), cela fait un grand nombre de contrôles effectués. Je me demande si cela n'a pas une répercussion sur les performances et s'il ne serait pas judicieux d'utiliser une autre pratique qui consisterait à ne pas tester la présence d'offset dans un cas où nous souhaitons utiliser '' (chaîne vide) à la place d'une valeur non présente (comme dans l'exemple précédent).

Si fonctionnellement nous maîtrisons le fait que la valeur peut être vide, pourquoi forcément la tester ? En production, les notices PHP ne sont pas remontées et l'appli se comporte correctement.

Nous pourrions utiliser l'exemple 1 sans avoir a tester la présence de l'offset.

Un autre cas pourrait-être d'utiliser un @ afin de ne pas relever de notice mais je trouve que ce procédé ne permettrait pas de débugguer le cas échéant en relevant le niveau des notices dans le php.ini.

ex 3 :
$strMaVariable = 'Ma phrase : '.@$aMonArray[0];
Voila, donc ma question est : Est-ce que le fait de tester la présence d'un offset pour un tableau est forcément judicieux sachant que ça peut avoir tendance à complexifier la lecture du code et que ça a un impact sur les performances ?

Merci pour vos réponses.