25

I have a function that takes in a set of parameters, then applies to them as conditions to an SQL query. However, while I favored a single argument array containing the conditions themselves:

function searchQuery($params = array()) {
    foreach($params as $param => $value) {
        switch ($param) {
            case 'name':
                $query->where('name', $value);
                break;
            case 'phone':
                $query->join('phone');
                $query->where('phone', $value);
                break;
        }
    }
}

My colleague preferred listing all the arguments explicitly instead:

function searchQuery($name = '', $phone = '') {
    if ($name) {
        $query->where('name', $value);
    }

    if ($phone) {
        $query->join('phone');
        $query->where('phone', $value);
    }
}

His argument was that by listing the arguments explicitly, the behavior of the function becomes more apparent - as opposed to having to delve into the code to find out what the mysterious argument $param was.

My problem was that this gets very verbose when dealing with a lot of arguments, like 10+. Is there any preferred practice? My worst-case scenario would be seeing something like the following:

searchQuery('', '', '', '', '', '', '', '', '', '', '', '', 'search_query')

xiankai
  • 373
  • 1
  • 3
  • 6
  • 1
    If the function expects specific keys as parameters, at least those keys should be documented in a DocBlock - that way IDEs can show the relevant information without having to delve into the code. http://en.wikipedia.org/wiki/PHPDoc – Ilari Kajaste Oct 01 '13 at 06:29
  • 2
    Performance tip: The `foreach` is unnecessary in this instance, you could use `if(!empty($params['name']))` instead of `foreach` and `switch`. – chiborg Oct 01 '13 at 07:19
  • 1
    You now have one method which you use. I would suggest to take a look here: http://book.cakephp.org/2.0/en/models/retrieving-your-data.html#creating-custom-find-types for creating more methods. They can even be magically generated for standard finds and developed in custom for specific searches. In general that makes a clear api for the users of the model. – Luc Franken Oct 01 '13 at 08:54
  • this example seems to call for a builder patterns really – ratchet freak Oct 01 '13 at 09:26
  • 1
    related: [Passing compound object for parameters](http://programmers.stackexchange.com/questions/152965/passing-compound-object-for-parameters) – gnat Oct 01 '13 at 14:15
  • also related: [PHP Function Arguments - Use an array or not?](https://stackoverflow.com/questions/10185634/php-function-arguments-use-an-array-or-not) – rink.attendant.6 Jan 03 '15 at 09:45
  • 2
    A note on the 'performance tip' above: don't blindly use `!empty($params['name'])` to test for parameters - for example, the string "0" would be empty. It's better to use `array_key_exists` to check for the key, or `isset` if you don't care about `null`. – AmadeusDrZaius Feb 24 '15 at 10:05
  • I strongly agree with you, not with your colleague. The value of a cleaner API and the ability to add parameters on a backward compatible basis far outweigh the arguments listed explicitly. If he can't easily understand how to determine the arguments required, tell him to get a better IDE. – MikeSchinkel Oct 18 '18 at 22:04

5 Answers5

28

IMHO your colleague is correct for the above example. Your preference might be terse, but its also less readable and therefore less maintainable. Ask the question why bother writing the function in the first place, what does your function 'bring to the table'- I have to understand what it does and how it does it, in great detail, just to use it. With his example, even though I am not a PHP programmer, I can see enough detail in the function declaration that I do not have to concern myself with its implementation.

As far as a larger number of arguments, that is normally considered a code smell. Typically the function is trying to do too much? If you do find a real need for a large number of arguments, it is likely they are related in some way and belong together in one or a few structures or classes (maybe even array of related items such as lines in an address). However, passing an unstructured array does nothing to address the code smells.

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • As for the need of a large number of arguments, the function is essentially taking zero or more arguments, and then limiting the result set by those arguments. The arguments themselves don't have much to do with each other (as distinct SQL clauses), and may not even have the same structure (one can be a simple WHERE, but another would require several JOINs in addition to the WHERE). Would it still be considered a code smell in this specific case? – xiankai Oct 01 '13 at 07:11
  • 3
    @xiankai In that example I would maybe make one array param for `where` arguments, one for `join` specifiers etc. By naming them appropriately that would still be self-documenting. – Jan Doggen Oct 01 '13 at 08:05
  • What if I use setter/getter instead and I don't pass argument at all? Is it a bad practice? Is it not a purpose of using setter/getter? – lyhong Dec 08 '15 at 06:45
  • I would challenge that the OP's preference is "less readable" (how?) and less maintainable. searchQuery('', '', '', '', 'foo', '', '', '', 'bar') is far less readable or maintainable than searchQuery([ 'q' => 'foo', 'x' => 'bar']) A large number of arguments is non-necessarily a code-smell either; a query(), for example. And even for a smaller number of arguments, the lack of consistency in argument order that occurs when arguments are passed directly illustrates what a bad idea it is to hardcode parameters. Just look at string and array functions in PHP for said inconsistency. – MikeSchinkel Oct 18 '18 at 22:10
4

My answer is more or less language agnostic.

If the only purpose of grouping arguments in a complex data structure (table, record, dictionary, object...) is to pass them as a whole to a function, better avoid it. This adds a useless layer of complexity and makes your intention obscure.

If the grouped arguments have a meaning by themselves, then that layer of complexity helps understand the whole design: name it layer of abstraction instead.

You may find that instead of a dozen individual arguments or one big array, the best design is with two or three arguments each grouping correlated data.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
1

In your case, I would prefer your colleague's method. If you were writing models and I was using your models to develop over them. I see the signature of your colleague's method and can use it immediately.

While, I would have to go through the implementation of your searchQuery function to see what parameters are expected by your function.

I would prefer your approach only in the case when the searchQuery is limited to searching only within a single table, so there will be no joins. In that case my function would look like this:

function searchQuery($params = array()) {
    foreach($params as $param => $value) {
        $query->where($param, $value);
    }
} 

So, I immediately know that the elements of array are actually the column names of a particular table which the class having this method represents in your code.

Ozair Kafray
  • 840
  • 1
  • 8
  • 15
1

Do both, sort of. array_merge allows for an explicit list at the top of the function, as your colleague likes, while keeping the parameters from getting unwieldy, as you prefer.

I also strongly suggest using @chiborg's suggestion from the question comments - it's a lot clearer what you intend.

function searchQuery($params = array()) {
    $defaults = array(
        'name' => '',
        'phone' => '',
        ....
    );
    $params = array_merge($defaults, $params);

    if(!empty($params['name'])) {
        $query->where('name', $params['name']);
    }
    if (!empty($params['phone'])) {
        $query->join('phone');
        $query->where('phone', $params['phone']);
    }
    ....
}
Izkata
  • 6,048
  • 6
  • 28
  • 43
0

Also you could pass a string resembling a query string, and use parse_str (because it seems you are using PHP, but other solutions are probably available in other languages) to process it into an array inside the method:

/**
 * Executes a search in the DB with the constraints specified in the $queryString
 * @var $queryString string The search parameters in a query string format (ie
 *      "foo=abc&bar=hello"
 * @return ResultSet the result set of performing the query
 */
function searchQuery($queryString) {
  $params = parse_str($queryString);
  if (isset($params['name'])) {
    $query->where('name', $params['name']);
  }
  if (isset($params['phone'])) {
    $query->join('phone');
    $query->where('phone', $params['phone']);
  }
  ...

  return ...;
}

and call it like

$result = searchQuery('name=foo&phone=555-123-456');

You can use http_build_query to convert from an associative array to a string (the reverse that parse_str does).

Carlos Campderrós
  • 805
  • 1
  • 7
  • 13