Arguments de la fonction PHP - Utilisez un tableau ou non?

J'aime créer mes fonctions PHP à l'aide de la clé=>paires de valeur (tableaux) comme arguments à la place des paramètres individuels.

Par exemple, je préfère:

function useless_func($params) {
    if (!isset($params['text'])) { $params['text'] = "default text"; }     
    if (!isset($params['text2'])) { $params['text2'] = "default text2"; }   
    if (!isset($params['text3'])) { $params['text3'] = "default text3"; }   
    echo $params['text'].$params['text2'].$params['text3'];
    return;
}

Et je n'aime pas:

function useless_func($text = "default text", $text2 = "default text2", $text3 = "default text3") {
        echo $text.$text2.$text3;
    return;
}

J'avais d'abord vu les choses de cette façon approfondie dans la WordPress base de code.

La raison pour laquelle je préfère les tableaux:

  • Les arguments de la fonction peut être fourni dans n'importe quel ordre
  • Plus facile à lire le code /plus d'auto-documentation (à mon avis)
  • Moins sujette aux erreurs, parce que lors de l'appel d'une fonction je doit enquêter sur la bonne matrice de touches

J'ai été discuter avec un collègue et il dit que c'est inutile et juste conduit à un code supplémentaire et il est beaucoup plus difficile de définir les valeurs par défaut. Fondamentalement, il n'est pas d'accord avec moi complètement sur les trois points.

Je suis à la recherche de conseiller et de conseils d'experts qui pourraient être en mesure de fournir un aperçu: Quelle est la meilleure ou la plus bonne façon de le faire?

source d'informationauteur ethanpil

  1. 15

    Bien, c'est un peu utile. Mais pour certains des arguments qui passe toujours, il est préférable d'utiliser classique en passant comme function some($a1, $a2). Je suis en train de faire comme ça dans mon code:

    function getSome(SomeClass $object, array $options = array())
{
    //$object is required to be an instance of SomeClass, and there's no need to get element by key, then check if it's an object and it's an instance of SomeClass

    //Set defaults for all passed options
    $options = array_merge(array(
        'property1' => 'default1',
        'property2' => 'default2',
        ... => ...
    ), $options); 
}

    Donc, comme vous pouvez le voir j'aime ce style de code trop, mais pour la base d'arguments je préfère le style classique, car de cette manière PHP contrôles de plus en plus de choses qui dois-je, si j'ai utilisé le code de style.

  2. 12

    Ne le faites pas!

    Passer le tout dans un tableau est une mauvaise idée, la plupart du temps.

    • Il empêche les gens d'utiliser votre fonction sans savoir de quoi il a besoin pour fonctionner.
    • Il vous permet de créer des fonctions ayant besoin de beaucoup de paramètres lorsque vous devriez probablement créer une fonction avec plus précis argument besoins et une étroite objectif

    Il semble que le contraire de injecter en fonction de ce dont il a besoin.

    Les arguments de la fonction peut être fourni dans n'importe quel ordre

    Je n'ai pas cette préférence. Je ne comprends pas ce besoin.

    Plus facile à lire le code /plus d'auto-documentation (à mon avis)

    La plupart des IDEs, vous présente les arguments en fonction des besoins. Si on voit une déclaration de fonction comme foo(Someclass $class, array $params, $id) il est très clair que la fonction de besoins. Je suis en désaccord que d'un seul param argument est plus facile de lire ou d'auto-documentation.

    Moins sujette aux erreurs, parce que lors de l'appel d'une fonction je doit enquêter sur la bonne matrice de touches

    De permettre aux gens de passer un tableau sans savoir que les valeurs par défaut n'est pas près de "pas sujettes à l'erreur". Rendre obligatoire pour les gens à lire votre fonction avant de l'utiliser, il est un moyen sûr pour elle de ne jamais être utilisé. Indiquant qu'il a besoin de trois arguments avec leurs valeurs par défaut est moins enclins à faire des erreurs parce que les gens l'appel de votre fonction sera de connaître les valeurs des paramètres par défaut, et la confiance qu'il présentera les résultats qu'ils attendent.

    Si le problème que vous essayez de résoudre un trop grand nombre d'arguments, la bonne décision est de revoir vos fonctions en de plus petits, de ne pas masquer la fonction dépendances derrière un tableau.

  3. 9

    Je suis en supposant que vous vous posez la question de savoir si c'est Une Bonne Chose à écrire tous les fonctions de sorte qu'ils acceptent qu'un seul argument, et pour que cet argument un tableau?

    Si vous êtes la seule personne qui est toujours à travailler sur votre code, puis vous pouvez faire ce que vous aimez. Toutefois, en passant par toutes les valeurs d'argument par l'intermédiaire d'un tableau, quelqu'un d'autre va avoir plus de mal à comprendre en quoi la fonction et pourquoi /comment il pourrait l'utiliser, surtout si elles sont l'aide d'un IDE de l'auto-complétion pour les noms de fonction, etc. Ils ne pas l'appeler la fonction "signature" pour rien.

    Je recommande les paramètres de tableau sont réservées pour les éléments où vous ne savez pas combien il y aura (par exemple, une série d'éléments de données), ou pour des groupes d'options /paramètres (ce qui est peut-être ce qui se passe dans le WordPress exemple que vous évoquez?).

    Si vous continuez avec une approche globale à des arguments de type tableau, alors vous devriez au moins être conscient de son impact sur la lisibilité et de prendre quelques mesures pour lutter contre ce problème.

  4. 5

    Votre co-travailleur est à droite. Non seulement est-il plus de code pour la même fonctionnalité, il est plus difficile à lire et qui a probablement une baisse des performances (Car vous avez besoin de les appeler isset pour chaque param et vous avez besoin d'accéder à un tableau de définir des valeurs).

  5. 4

    Ce frontières sur Cargo Culte de la programmation. Vous dire que c'est plus lisible et l'auto-documentation. Je voudrais demander comment? Pour savoir comment utiliser votre fonction/méthode que j'ai à lire dans le code lui-même. Il n'y a aucun moyen que je peux savoir comment l'utiliser à partir de la signature elle-même. Si vous utilisez une demi-décent de l'IDE ou l'éditeur qui prend en charge la signature de la méthode allusion ce sera un vrai pain PITA. De Plus, vous ne pourrez pas utiliser de PHP de type-hinting syntaxe.

    Si vous trouvez que vous êtes le codage d'un chargement de paramètres, en particulier les paramètres facultatifs, puis il suggère qu'il pourrait y avoir quelque chose de mal avec votre conception. Considérez comment vous pouvez aller à ce sujet. Si certains ou tous les paramètres sont liés, alors peut-être qu'ils appartiennent à leur propre classe.

  6. 4

    À l'aide de array_merge() fonctionne bien, mais à l'aide de la + opérateur peut être utilisé aussi; il fonctionne dans l'autre sens, il ajoute que les valeurs par défaut où l'on n'a pas encore été donné.

    function useless_func(array $params = array())
{
    $params += array(
        'text' => 'default text',
        'text2' => 'default text2',
        'text3' => 'default text3',
    );
}

    Voir aussi: La fonction de la matrice de Passage de clé définie

    Quelques choses que vous n'avez pas avec l'utilisation de tableaux comme arguments de la fonction est:

    1. type de contrôle (applicable uniquement pour les objets et les tableaux, mais il peut être utile et, dans certains cas attendus).
    2. smart(er) des éditeurs de texte, avoir un aperçu de code qui va afficher les arguments d'une fonction comprend; à l'aide de tableaux enlève cette fonctionnalité, cependant, vous pouvez ajouter les clés possibles dans la fonction docblock.
    3. en raison #2, il devient alors plus enclins à faire des erreurs, parce que vous pourriez vous faites une erreur de saisie de la clé du tableau.
  7. 0

    Votre co-travailleur est fou. Il est parfaitement acceptable d'un tableau comme argument de fonction. Il est répandu dans de nombreuses applications open source, y compris de Symfony et Doctrine. J'ai toujours suivi l'argument 2 de la règle, si une fonction a besoin de plus de deux arguments, OU vous pensez qu'il va utiliser plus de deux arguments à l'avenir, utiliser un tableau. OMI cela permet une plus grande souplesse et permet de réduire le code appelant les défauts qui peuvent survenir si un argument est passé de manière incorrecte.

    Bien sûr, il faut un peu plus de travail pour extrapoler les valeurs de la matrice, et vous n'avez de compte pour les éléments requis, mais il ne l'ajout de fonctionnalités beaucoup plus facile, et est de loin préférable que le passage de l'13 arguments de la fonction à chaque fois qu'il doit être appelé.

    Voici un extrait de code d'afficher les vs en option params juste pour vous donner une idée:

    //Class will tokenize a string based on params
public static function tokenize(array $params)
{
    //Validate required elements
    if (!array_key_exists('value', $params)) {
        throw new Exception(sprintf('Invalid $value: %s', serialize($params)));
    }        

    //Localize optional elements
    $value            = $params['value'];
    $separator        = (array_key_exists('separator', $params)) ? $params['separator'] : '-';
    $urlEncode        = (array_key_exists('urlEncode', $params)) ? $params['urlEncode'] : false;
    $allowedChars     = (array_key_exists('allowedChars', $params)) ? $params['allowedChars'] : array();
    $charsToRemove    = (array_key_exists('charsToRemove', $params)) ? $params['charsToRemove'] : array();

....
  8. 0

    @Mike, vous pouvez également "extract ()" $params argument dans les variables locales, comme ceci:

    //Class will tokenize a string based on params
public static function tokenize(array $params)
{
    extract($params);
    //Validate required elements
    if (!isset($value)) {
        throw new Exception(sprintf('Invalid $value: %s', serialize($params)));
    }

    //Localize optional elements
    $value         = isset($value) ? $value : '';
    $separator     = isset($separator) ? $separator] : '-';
    $urlEncode     = isset($urlEncode) ? $urlEncode : false;
    $allowedChars  = isset($allowedChars) ? $allowedChars : array();
    $charsToRemove = isset($charsToRemove) ? $charsToRemove : array();

    ....

    Même de la mise en œuvre, mais plus court.

  9. 0

    J'ai utilisé des tableaux de substituer une longue liste de paramètres en de nombreuses occasions et il a bien fonctionné. Je suis d'accord avec ceux qui sont dans ce post qui ont mentionné à propos des éditeurs de code n'étant pas en mesure de fournir des conseils pour les arguments. Le problème est que si j'ai 10 arguments, et les 9 premiers sont vides/null ça devient lourd lors de l'appel de cette fonction.

    Je serais également intéressé par une façon de re-conception d'une fonction qui nécessite beaucoup d'arguments. Par exemple, lorsque nous avons une fonction qui construit des instructions SQL basé sur certains arguments mis:

    function ($a1, $a2, ... $a10){

        if($a1 == "Y"){$clause_1 = " something = ".$a1." AND ";}
        ...
        if($a10 == "Y"){$clause_10 = " something_else = ".$a10." AND ";}

        $sql = "
        SELECT * FROM some_table 
        WHERE
        ".$clause_1." 
        ....
        ".$clause_10." 
        some_column = 'N'
        ";

        return $sql;
    }

    Je voudrais voir PHP divertir l'ajout d'un natif fonction d'assistance qui pourraient être utilisés dans la fonction appelée aider dans le passage d'un tableau de paramètres, de la nécessaire vérification de type. PHP reconnu ce fait dans une certaine mesure par la création de la func_get_args() fonction qui permet d'arguments à passer dans n'importe quel ordre. MAIS ce sera seulement de transmettre une COPIE des valeurs, donc, si vous voulez passer des objets à la fonction, ce sera un problème. Si une telle fonction existe, alors les éditeurs de code serait en mesure de prendre cette place et fournir des détails sur les arguments possibles.