Multiple strings vs Dictionary of strings as method parameters

Question

I have some methods that take 20 or more strings as parameters. I was wondering what works better: passing 20 string parameters to the method or putting them all in a dictionary and passing it as only parameter.

Multiple strings:

public Boolean isNice(string aux, string aux2, string aux3, string aux4, string aux5, string aux6, string aux7,
    string aux8, string aux9, string aux10, string aux11, string aux12, string aux13, string aux14, string aux15, string aux16)
{
    string foo1 = aux;
    string foo2 = aux2;
    // etc

    return true;
}

public void yeah()
{
    string aux = "whatever";
    string aux2 = "whatever2";
    // etc

    isNice(aux, aux2, ..., ..., ...);                 
}

Dictionary of strings

public Boolean isNice(Dictionary<string, string> aux)
{
    string foo1 = aux["aux1"];
    string foo2 = aux["aux2"];
    // etc

    return true;
}

public void yeah()
{
    string aux = "whatever";
    string aux2 = "whatever2";
    // etc

    Dictionary<string, string> auxDict = new Dictionary<string,string>();

    auxDict.Add("key1", aux);
    auxDict.Add("key2", aux2);
    // etc

    isNice(auxDict);
}

My question is regarding performance, readability and code simplicity.

Right now I'm using multiple strings: should I use dictionaries instead?

Answer 1

This depends. Are all 20 parameters required for the function to work?

If so, create a data type that can communicate all 20 values and pass in an instance of that data type. You could create helper classes to easily initialize that type of object. You can easily pass in a new instance of that data type, and provide flexible ways to initialize the type:

isNice(new niceParams
   {
      aux1 = "Foo",
      aux2 = "Bar"
      // ...
   }
);

If not, put the optional parameters at the end of the signature, and give them default values.

public Boolean isNice(string req1, string req2, string optional1 = null)

This way, you have overloads to specify exactly which values you want to provide.

Another benefit of this is you can used named parameters to call the function:

isNice(req1, req2, optional1: "Foo", optional15: "Bar");

With that said, I would not use a dictionary. It forces the caller to understand the signature, and completely breaks any compiler type safely. What if required values aren't provided? What if a key is misspelled? All this checking has to now be done at runtime, causing errors that can only be caught at runtime. To me, it seems to be asking for trouble.

Answer 2

The main difference is that in case when you have 20 string parameters the compiler will ensure that all of them are explicitly set, even if they are set to null . In case of passing a collection the compiler will not be able to detect that somebody has forgotten to set the aux17 parameter: the code that uses a dictionary-based API would continue to compile, so you would be forced to add an extra check at run-time.

If it is OK with your code to not have a compiler check, for example, because all your string values are optional, then a collection-based approach is easier to maintain.

The difference in speed cannot be predicted until you implement the change. A collection-based approach would perform an additional memory allocation, so it would consume more CPU cycles. On the other hand, the difference may be too small to have a real impact on the overall performance of your program.

Note that since your parameters are named uniformly, it appears that they may be placed in a "flat" collection, rather than a dictionary. For example, you could make an API taking a list or an array of strings. In case of an array, you could also make your method take variable number of parameters, so that the callers could use the old syntax to call your method:

public bool isNice(params string[] args)