33 parameters for a function?! Seriously!?

Cornstalks · 2013-06-18T05:29:01

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]

RivieraKid

706

January 10, 2009 05:15 PM

i dont even think stuffing 33 parameters into a struct/class is a good solution. What a mess.

trzy

100

January 10, 2009 07:32 PM

Quote: Original post by RivieraKid
i dont even think stuffing 33 parameters into a struct/class is a good solution. What a mess.

I agree. Unless the function is called very frequently (in which case maintaining a struct with configuration information would be far more efficient), creating another layer of abstraction seems rather pointless.

Is this,

params.a = 1.0;...params.z = 26.0;Init(&params);

really any better than

Init(1.0,     ...,     26.0);

?

I submit that it is not. The only advantage of the first is that it is clear which argument corresponds to which parameter. It's not immediately obvious from the latter, although that could be rectified with comments.

Init(1.0,     // a     ...     26.0);   // z

----Bart

benryves

2,001

January 10, 2009 08:27 PM

Quote: Original post by trzy
Quote: Original post by RivieraKid
i dont even think stuffing 33 parameters into a struct/class is a good solution. What a mess.

I agree. Unless the function is called very frequently (in which case maintaining a struct with configuration information would be far more efficient), creating another layer of abstraction seems rather pointless.

Or, indeed, if a lot of parameters have default values - but this is better resolved with named/optional parameters.

[Website] [+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++]

polymorphed

272

January 10, 2009 09:03 PM

Quote: Original post by trzy
Is this,

*** Source Snippet Removed ***

really any better than

*** Source Snippet Removed ***

?

When you make a function which takes 33 parameters, you (I'm taking the role of the processor here, bear with me) have to fill in each and every one of those variables on to the stack when the function is called. This comes at a cost, especially if the function is called a lot. By passing a reference/pointer instead of 33 parameters, you'll only need 4 bytes on the stack, as opposed to 132.

while (tired) DrinkCoffee();

Way Walker

745

January 10, 2009 09:28 PM

Quote: Original post by RivieraKid
i dont even think stuffing 33 parameters into a struct/class is a good solution. What a mess.

Right, it probably wouldn't help matters to just dump all the parameters in one struct. What you'd want to do is group similar parameters into different structs to make the mess of 33 parameters conceptually simpler to someone reading the code. It'd make it faster to locate the parameter of interest.

And, looking at the bit that was posted, I'd probably have to be tearing apart an object to pass it to that function.

namespace Application {struct Application {            ApplicationType type;            std::string     version;};}namespace Asset {struct Video {            int                     width;            int                     height;            float                   duration;            std::string             frameRate;            std::string             dataRate;            Asset::VideoBitRateMode videoBitRateMode;            std::string             codec;};struct Audio {            std::string             dataRate;            Asset::AudioBitRateMode audioBitRateMode;            std::string             codec;};struct Asset {            std::string shortName;            std::string description;            std::string authorName;            std::string fileName;            std::string fileType;            Video video;            Audio audio;};struct Paths {            std::string asset;            std::string shortPreview;            std::string mainThumbnail;            std::string summaryThumbnails;};}void myUploadAsset(            const Application::Application& application,            const Asset::Paths&             pathTo,            const Asset::Asset&             asset,            const Asset::Asset&             source,            const std::string&              presetXML,            const std::string&              filter,            bool (*progressCallback)(float)) {            uploadAsset(                        applicaiton.type, application.version,                        pathTo.asset, pathTo.shortPreview,                         pathTo.mainThumbnail, pathTo.summaryThumbnails,                        asset.shortName, asset.description,                        asset.video.frameRate, asset.video.width, asset.video.height,                        asset.audio.dateRate,    asset.video.dataRate,                        asset.audio.bitRateMode, asset.video.bitRateMode,                        asset.video.duration,                        presetXML,                        asset.fileType,                        filter,                        asset.audio.codec, asset.video.codec,                        asset.authorName,                        source.fileName, source.fileType,                        source.audio.codec, source.video.codec,                        source.video.frameRate, source.video.width, source.video.height,                        source.audio.dataRate,    source.video.dataRate,                        source.audio.bitRateMode, source.video.bitRateMode,                        progressCallback            );}

trzy

100

January 11, 2009 04:44 AM

Quote: Original post by polymorphed
When you make a function which takes 33 parameters, you (I'm taking the role of the processor here, bear with me) have to fill in each and every one of those variables on to the stack when the function is called. This comes at a cost, especially if the function is called a lot. By passing a reference/pointer instead of 33 parameters, you'll only need 4 bytes on the stack, as opposed to 132.

I mentioned that it doesn't matter for functions which are called infrequently (such as initialization functions, which may be called once or only a few times per program session.) In that case, pushing things on the stack is no big deal. If you had to set up all the parameters in a struct each time, you wouldn't save anything, because you would still be making just as many memory writes as pushing everything on the stack.

----Bart

Dmytry

1,151

January 11, 2009 12:49 PM

Quote: Original post by MikeTacular
....

its actually fairy common to pass tens or hundreds of arguments to function.... that's called OOP and arguments are called "members" or "fields" :P It also has nicer syntax than just listing them in the (,,,,) list.
(joking of course.)

More seriously though. I never seen a function taking many arguments, which are so unrelated as that you couldn't group them into classes. Example, a function that takes 2 3-d vectors... of course you should make 3d vector a class.

[Edited by - Dmytry on January 11, 2009 1:49:40 PM]

Cornstalks

Author

7,033

January 11, 2009 02:36 PM

Quote: Original post by ToohrVyk
I once generated a function with 81 parameters—each parameter was a distinct Su Doku cell, and I needed to manipulate them by name.

I don't get why you had to use 81 parameters. Seems like there would be a cleaner, less error prone solution.

Quote: Original post by trzy
*snip*

I beg to differ. The difference is readability. Intellisense makes it really easy to build a struct like that, because each time you access a member with '.', you get a nice, readable list of members. If you're trying to call the function with 34 arguments, when you write '(' intellisense is going to give you a boat load of parameters, many of which look like this: const std::string& parameterName. The const std::string& kills readability. And it's easy to forget which parameter your on, so one mistake can cause a huge ripple effect. You also suggest using comments to clarify the 34 parameters. Not only does that take time, but it requires the programmer to know exactly what all 34 parameters are and (here's the hard part) exactly what order they're in. With a struct, you can fill them in whatever order you like, and the member names are named reasonably so you shouldn't need any comments. Hence increasing productivity and readability.

Quote: Original post by Way Walker
*snip*

I actually really like that solution. Cramming all 34 parameters into an object does seem messy. Splitting them up into coherent objects like that makes a lot of sense. I'll suggest something like that.

Quote: Original post by d000hg
It's also common for technical people to think their bosses are stupid because they are less technically able than they are. This is logically ridiculous. Your boss has to manage people, organise schedules and budgets, keep clients happy etc, which all take time and require knowledge and skills. Only a very special person can do all that and still know as much as his development team. In fact even if he is a coder by trade, a good boss would be hiring coders who were better than him.
Expecting your boss to be at the same level as you on your specialty is unreasonable. Programmers need to learn not to feel superior to people who aren't great programmers, and how to communicate with less technical people.

I hope you weren't targeting me in that. My boss is a programmer/software engineer and mostly works in Java. The reason the function grew to 34 parameters is because it started out with about 5 parameters (we hardcoded the rest of the values into the function while testing), but when we removed those hardcoded testing values, we had to suddenly expand the function to take all the values we needed. It just hadn't been planned out (not that that's a good excuse, we should have planned it out long ago). Anyway, that's how it evolved from a 5ish parameter function into a 34 parameter beast.

[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Rydinare

487

January 11, 2009 02:38 PM

Seriously. That's a hazard which begs for redesign. Neither solution is really great. You simply went from an F up to a D-. What you really need is to componentize the different facilities... but if it took that much just to get them away from a 33 argument parameter list, yikes. Good luck.

EvilNando

96

January 11, 2009 05:50 PM

Quote: Original post by d000hg
Quote: Original post by MikeTacular
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.
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.

Thank you sir , never laughed so hard in my life

seriously

33 parameters for a function?! Seriously!?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

33 parameters for a function?! Seriously!?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines