Would you ever write or use a function that takes 33 parameters? And how can you help someone see that 33 is just too many? Even though all 33 are absolutely needed, how can you help them see that passing a single object containing all the needed info would be better? Background info/story: I'm at work ("working," of course) and my boss recently had me make an API change to an SDK we're making. He does the Java version of the SDK, and I do the C++. Basically he (and others) decide how it's going to be, then he does it in Java and gives it to me to turn into C++. He just gave me a function that takes 33 arguments. 33! Most of them are strings, but there is a healthy(?) mix of ints, floats, and enums, and they are in no particular order. It's horribly confusing. And this isn't the first time. There was a Java function they had me clean up that probably had about 30ish parameters (I cut it in half but still, why?). I suggested making a struct or class that contains all the necessary parameters that we pass into the function. That way we can get all 33 parameters we need but only pass 1 object to the function. He agreed but said "the guys" (dunno who they are... his management maybe?) like to use parameters and were pretty stiff about it. He said it was probably so it could work with legacy code and that "the guys" say objects cause portability issues. Ummm... portability issues? I'm not buying that one. The object would be 100% portable. And it's a static library so there aren't the DLL issues either. And I'm definitely not buying the legacy code thing, since this is a brand new SDK we're making. There is no legacy code. Anyway, it's hard to use (and maintain) a function with 33 arguments, especially when they usually change every week when the API gets updated. I like my boss; I don't blame him for the parameter mess. He's a smart guy. So I tell myself I blame his boss. Is this normal? Do most work places do this (by "this" I mean use a ridiculous amount of arguments for a function)? [Edited by - MikeTacular on January 9, 2009 4:06:38 PM]

Quote:Original post by MikeTacular
Is this normal?

Nope. The normal thing would be to just pass a pointer/reference to an object containing said 32 arguments. I can't imagine why you'd have any portability issues with plain objects, unless you're planning to port it to FORTRAN. [smile]

That's exactly what I was thinking. And this is only being made for Windows and Mac OS X. Just passing an object by reference would make life so, so much easier. Not to mention that in the time it took for me to post that, a new API update was made and now there are 34 parameters... sweet...

Plus passing an object would help not break legacy code. I have to keep rewriting my test program everytime the parameters change... that's what I'm doing right now.

[Edited by - MikeTacular on January 9, 2009 4:48:22 PM]

I haven't seen that many parameters in a function. I bet that really cuts down readability. What does it even do? If possible, I would think breaking it up into a bunch of smaller methods that each do their own part would be much better. Of course you can cannot even convince them to wrap up 33 parameters into a class I don't think you could get them to rework the system.

Is this kinds of design typical of the project or is this just one strange piece?

Oh it absolutely kills readability. And trying to call the function is impossible without Intellisense's help (not that it can help that much with a function that big) or without looking at the function declaration. It's a method that uploads a video, thumbnails, a short preview, etc. to a web server. Most of the parameters have to do with what type of video it is, how it was encoded, how it used to be encoded before it was converted (though I don't why they think the video was necessarily converted), etc. It all has to be uploaded at once, so breaking it up can't be done.

Every other function in the project is reasonable and only take 1, 2, or 3 parameters (and they either take primitive data types, C++ STL objects, or classes from the project, so it's a good mix). Although there was one function in another project I did for them that took about 25 or so arguments. I was able to clean it up and cut it in half, but still, even cleaned up it was a ton of arguments. It was in Java so at least when I wrote String it was relatively clean. In my 34 argument C++ function, its riddled with const std::string&, which makes reading even harder.

33 is the age at which Jesus died and resurrected. You could take this as an opportunity to propose using "at least" a friggin struct.

If the function is widely used, then you could propose writing a new one and leave the other as "deprecated".

Quote:Original post by MikeTacular
And how can you help someone see that 33 is just too many?

Entangle the function with a recursive algorithm of some kind that leads to busting the stack and killing the app.

That reminds me of the joy that is Microsoft Office's COM API, but that's not quite 33. Part of the problem is C#'s lack of support for named or optional parameters, which is fortunately being remedied in C# 4.0!