26

I am new to C# and have to maintain a C# Application. Now I've found a method that has 32 Parameters (not auto-generated code).

From C/C++ I remember the rule of thumb "4 Parameters". It may be an old-fashioned rule rooting back to old 0x86 compilers, where 4 Parameters could be accommodated in registers (fast) or on stack otherwise.

I am not concerned about performance, but I do have a feeling that 32 parameters per functions are not easy to maintain even in C#.

Or am I completely not up to date?

What is the rule of thumb for C#?

Thank you for any hint!

willem
  • 25,977
  • 22
  • 75
  • 115
Valentin H
  • 7,240
  • 12
  • 61
  • 111

11 Answers11

25

There is no general consensus and it depends on who you ask.

In general - the moment readability suffers, there are too many...

Bob Martin says the ideal number of parameters is 0 and that 3 is stretching it.

32 parameters is a massive code smell. It means the class has way too many responsibilities and needs to be refactored. Even applying a parameter object refactoring sounds to me like it would hide a bad design rather than solve the issue.

From Clean Code Tip of the Week #10:

Functions should have a small number of arguments. No argument is best, followed by one, two, and three. More than three is very questionable and should be avoided with prejudice.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • +1 Totally agree; at some point you have to set the 32 parameter values, whether it be on the constructor of the parameter object, the method itself or via auto-setting. – dash Sep 14 '12 at 21:13
  • 1
    :-) 0 Parameters? Hmm, I wonder, how he would implements e.g. int to string: _1ToString(); _2toString(); ... _42toString(); ... – Valentin H Sep 14 '12 at 21:16
  • But if the method is SaveCustomer, anyway you cut it you need the values whether as arguments or with the parameter object. Besides i believe that responsibilites come from methods rather than parameters – Carlos Grappa Sep 14 '12 at 21:16
  • 1
    @CarlosGrappa - If by "need the values" you mean that you need the address, order and order lines, billing details etc, I would say that your `SaveCustomer` is misnamed and is doing too much... – Oded Sep 14 '12 at 21:19
  • True, but the customer could have an Account, an Address, a PersonalDetails, an Order - already that could reduce the problem into 4 objects with 8 properties each - which is beginning to be more manageable. – dash Sep 14 '12 at 21:19
  • Just remembered listening to interesting podcast with B. Martin: http://www.se-radio.net/2009/11/episode-150-software-craftsmanship-with-bob-martin/ – Valentin H Sep 14 '12 at 21:20
  • Spliting it into objects is the way to go, but at the end there are 32 values, where its single object or 4. It's a desing issue, you shouldn't save the full customer if you update the address. But if he needs 32 values, he'll have'em :) – Carlos Grappa Sep 14 '12 at 21:23
  • @CarlosGrappa - No one argues that it is still 32 values. But splitting them between different objects makes the code base _much_ simpler to understand and maintain (assuming good factoring and naming). Having each such object responsible to one thing keeps complexity at bay. – Oded Sep 14 '12 at 21:24
12

Hmmm 32 parameters is way too much. There are as many rules as people i guess. However, common sense dictates that more than 6 becomes unwieldy.

When you have so many parameters it's always better to pass an object as a single parameter and have the parameters as properties, at least is easier to read.

O.O
  • 11,077
  • 18
  • 94
  • 182
Carlos Grappa
  • 2,351
  • 15
  • 18
  • 32 parameters sound crazy. @Carlos is right, use an objetct with propierties. – EdgarT Sep 14 '12 at 21:14
  • 1
    But then you have 32 properties on an object that have to be set at some point. 32 parameters is way too much, full stop. – dash Sep 14 '12 at 21:16
  • 2
    @dash any way you look at it, that function serves a purpose and needs 32 different values in order to serve that purpose. refactor all you want, at some point in the code, 32 different values need to be stored and passed somewhere. how those values get stored and passed is what's relevant and it's a lot cleaner to set 32 properties on an object and pass it as an argument to a function than it is to pass 32 parameters to a function. :) – Cypher Sep 14 '12 at 21:18
  • 2
    While I agree an object with that many properties is odd, sometime there is no option, you may split the fields in as many objects as you can, but if you really need the 32 values, ortodoxy goes through the window sadly. If the values are needed its all over. Any change in that probably is a major functional change to the application – Carlos Grappa Sep 14 '12 at 21:20
  • 3
    Unless, of course, you can split it into multiple objects with their own properties and responsibilities - which could make it much easier to maintain and manage :-) That's why I voted to close - it's all really opinion (except you are totally right, 32 is way too much!) – dash Sep 14 '12 at 21:21
5

C# doesn't limit maximum number of parameters, AFAIK.
But IL does: 0x1FFFFFFF.

Of course, this post isn't a guide to write methods with huge amount of parameters.

Dennis
  • 37,026
  • 10
  • 82
  • 150
4

I believe that a common feeling from the developer community is about 5 or 6 parameters maximum. The times that I've seen methods like yours, it is someone doing something like "SaveCustomer" and pass every field instead of passing a customer object.

SASS_Shooter
  • 2,186
  • 19
  • 30
2

There is no silver bullet answer for this. Everything depends on you and your dev group. The quantity of parameters may arrive also on numbers like 32, even if this leads to think about poor design, but this is kind of things that may happen to meet during career.

General agreement on this is

  • use as less as pssible

  • use overloaded functions, to slice parameters between different functions 

    func A(a,b)
{
    A(a,b,c);
}

  • can use params keyword to pass arbitrary information in array, like object[]

  • can use Key-value stores where you can hold a lot of information and recover it

In general they say that the code-line has not to be long as much then constrain you to scroll horizontally in your editor, even if this is not strictly related to question subject, but may lead to some ideas on it.

Hope this helps.

Druid
  • 6,423
  • 4
  • 41
  • 56
Tigran
  • 61,654
  • 8
  • 86
  • 123
1

You could take another approach by creating an object that is passed in as single parameter?

I have never head of a rule of thumb for parameters, but common sense and practicality usually prevails.

Mark Redman
  • 24,079
  • 20
  • 92
  • 147
1

While I suspect the question will get closed as argumentative, 32 is definitely too many.

One option is to look at the builder patter, which will at least make the task more readable.

Miserable Variable
  • 28,432
  • 15
  • 72
  • 133
1

I think nowadays the most important thing would be readability for humans as opposed to performance. I doubt that a similar performance behaviour exists in .NET anyway, but even if it did, code that is correct is infinitely more useful than code that performs slightly quicker but that does the wrong thing. By keeping it easy to understand, you increase the chances of the code being correct.

A handful of parameters - rarely beyond 5 in my experience - is best most of the time. You could consider refactoring code that requires more than this by providing the parameters in the form of properties on a class which the method is subsequently called on.

Stephen Hewlett
  • 2,415
  • 1
  • 18
  • 31
1

I think it is pleasant to have zero up to five parameters per method. But this depends on varying things, like coding style and class design.

Look at the .NET Framework, you will see often this:

  • A class with methods that almost have less or no parameters, but uses few properties to control the behavior of the class (instead of 30 parameters).

  • A class with huge set of methods with less or no paramters and with almost no properties. e.g. BinaryReader.

Keep your public API so simple as possible. Less parameters helps other developers to use your class without to learn to much about 'how it works'. Makes code more legible.

CodeTherapist
  • 2,776
  • 14
  • 24
1

Valentin you have right feeling, 32 parameters mean only one - something going totally wrong. From my past experience in C++, I saw only one "parameters" leader:
It was Win32 APi CreateWindow with 11 params.
You should never ever use such huge quantity of parameters.

From other hand, if you interested in question from theoretical point (probably it can be asked at interview) - How many parameters allowed for method?
So, here as was mention above C# method can have no more then 0x1FFFFFFF parameters (IL limitation).
You can use params[] array to set up such huge quantity.

And why exactly such limit?
Because, if you convert this value to bytes and multiple by reference size (4 bytes) you will receive exactly 2 GB.
There are 2 GB limitation on all objects in .NET and you are never allowed to create a single object that exceeds 2 GB.

Mykola Kushnir
  • 61
  • 6
0

As far as I know there isn't any hard and fast rule for how many parameters you should have. It depends entirely on what you are doing.

However for most applications, 32 parameters sounds like a bit too much. It might indicate a bad design. There might be a way to simplify things if you look closely.

Gigi
  • 28,163
  • 29
  • 106
  • 188