Followers 0

# 33 parameters for a function?! Seriously!?

## 55 posts in this topic

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]
0

##### Share on other sites
Quote:
 Original post by MikeTacularIs 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]
1

##### Share on other sites
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]
0

##### Share on other sites
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?
0

##### Share on other sites
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.
0

##### Share on other sites
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".
0

##### Share on other sites
Quote:
 Original post by MikeTacularAnd 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.

0

##### Share on other sites
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!
1

##### Share on other sites
Quote:
 Original post by benryvesThat 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!
Those are going to be so awesome!!! I can't wait. They should update GDI+ and such so you just pass in what you want. Having to retype defaults to get at something you want to define is pointless :P

0

##### Share on other sites
For a good laugh, turn that function into a variadic one.
0

##### Share on other sites
Quote:
 Original post by jantaFor a good laugh, turn that function into a variadic one.
Hahaha now that is tempting.

I just had a nice little chat with my boss and a coworker. My boss is all for using a struct/class, but my coworker isn't. He likes having a lot of parameters. He says it's like a shopping list. He also says there would be alignment issues between C and C++. But we're using C++ objects in the API (like std::string and std::vector)... how do I tell him that we aren't even targeting C? And as for possible alignment errors with C++, how do I combat him on that? Surely if there are alignment errors they'll show up in more than the struct we would be passing for that function? So why worry so much about that one struct that would simplify life so, so mch? And we're delivering libraries for all our targeted compilers and platforms, so that shouldn't be an issue. Someone give me some ammo for his alignment issues argument :)
0

##### Share on other sites
33 parameters sounds like a severe design WTF if you ask me. Personally, I consider six to be too many.
0

##### Share on other sites
Quote:
 Original post by MikeTacularHe likes having a lot of parameters. He says it's like a shopping list.

Oh come on! LOL!
0

##### Share on other sites
Quote:
 Original post by MikeTacularHe also says there would be alignment issues between C and C++.

He's wrong. Structs are aligned in the exact same way in C/C++. You can change the alignment to 1, 2, 4 or 8 bytes with compiler #pragmas anyway. You should ask him what he means specifically by "alignment errors".
0

##### Share on other sites
But why does you function need 33 inputs anyway? Couldn't you split that up, avoiding the many parameters vs. single struct argument entirely? I've never needed so many arguments in a function! Your program is crazy :)
0

##### Share on other sites
Quote:
Original post by polymorphed
Quote:
 Original post by MikeTacularIs 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]

Even then, I usually write a wrapper function or macro for the FORTRAN function which takes a struct or two as arguments.
0

##### Share on other sites
Quote:
 Original post by MikeTacularI just had a nice little chat with my boss and a coworker. My boss is all for using a struct/class, but my coworker isn't. He likes having a lot of parameters.
Who cares, it is your task and your boss is happy, just do it your way and if the coworker really whinges, tell him he's welcome to add an override that takes the parameters individually.

But, 33 is nothing.

0

##### Share on other sites
Quote:
 Original post by d000hgBut, 33 is nothing.

LOL, I remember that one. It sounds terrible for me to say this, but I hope someone lost their job over that abomination.
0

##### Share on other sites
SUCCESS!!!!!!!!!!!!!!!!! WOOHOO!!! After my coworker talked to another coworker today, he consented to letting a class be build with accessor methods that we could pass to the function instead of the 34 parameters. Finally! Hopefully management is cool with it too. And I was all ready to rate the 34-parameter function in WTFs/min (obligatory link for those who don't know the reference).

For those who are curious as to what our 34 parameters were, here's the function's declaration (hopefully I don't get in trouble for posting this):

uploadAsset(Application::ApplicationType application, const std::string& applicationVersion,            const std::string& pathToAsset, const std::string& pathToShortPreview,             const std::string& pathToMainThumbnail, const std::string& pathToSummaryThumbnails,            const std::string& shortName, const std::string& description,            const std::string& frameRate, int width, int height, const std::string& audioDataRate,            const std::string& videoDataRate, Asset::AudioBitRateMode audioBitRateMode,            Asset::VideoBitRateMode videoBitRateMode, float videoDuration, const std::string& presetXML,            const std::string& fileType, const std::string& filter, const std::string& audioCodec,            const std::string& videoCodec, const std::string& authorName, const std::string& sourceFileName,            const std::string& sourceFileType, const std::string& sourceAudioCodec,            const std::string& sourceVideoCodec, const std::string& sourceFrameRate, int sourceWidth,            int sourceHeight, const std::string& sourceAudioDataRate,            Asset::AudioBitRateMode sourceAudioBitRateMode, const std::string& sourceVideoDataRate,            Asset::VideoBitRateMode sourceVideoBitRateMode,            bool (*progressCallback)(float))

Imagine trying to call that function off the top of your head haha!

Just saw your post d000hg, and that function is a true, bona fide nightmare.
0

##### Share on other sites
Quote:
 Original post by d000hgBut, 33 is nothing.

Hmm. Wow. I'm genuinely surprised that the person who wrote that code was able to operate a keyboard.
0

##### Share on other sites
Ok ok. the ONLY place i can see ANYTHING like that is we have some macros / inline functions for transforming vertex data. They are something like 9 in and 3 out parameters.
A few cases we have some strange stuff because we init classes only using the
classA foo = {...}
classA foo(...);

and so there are wrapper macros that EMULATE the constructor format and thus can have tonnes of parameters.
0

##### Share on other sites
Quote:
 Original post by KulSeranOk ok. the ONLY place i can see ANYTHING like that is we have some macros / inline functions for transforming vertex data. They are something like 9 in and 3 out parameters.A few cases we have some strange stuff because we init classes only using theclassA foo = {...}syntax instead ofclassA foo(...);and so there are wrapper macros that EMULATE the constructor format and thus can have tonnes of parameters.

o_O

For purely educational purposes, why would you do such a thing?
0

##### Share on other sites
Quote:
Original post by Way Walker
Quote:
Original post by polymorphed
Quote:
 Original post by MikeTacularIs 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]

Even then, I usually write a wrapper function or macro for the FORTRAN function which takes a struct or two as arguments.

And even then, the more recent standards of FORTRAN (e.g. 2003) contain support for object-oriented programming, so even the good old grand daddy of programming languages should be able to handle passing a struct or an object through the parameter list :-)
0

##### Share on other sites
You should consider finding another job. You just received production code that has 33 function. Something is wrong here :|. No matter how good your boss is.
1

##### Share on other sites
Quote:
Original post by polymorphed
Quote:
 Original post by d000hgBut, 33 is nothing.

Hmm. Wow. I'm genuinely surprised that the person who wrote that code was able to operate a keyboard.
On the contrary, he must be quite good at typing, you noticed 100 lines were removed from the declaration right :)

0

## Create an account

Register a new account