• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# 33 parameters for a function?! Seriously!?

56 replies to this topic

### #21KulSeran  Members

Posted 09 January 2009 - 06:00 PM

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.

### #22Benjamin Heath  Members

Posted 09 January 2009 - 08:20 PM

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?

### #23sergamer1  Members

Posted 09 January 2009 - 08:56 PM

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 :-)

Posted 09 January 2009 - 09:37 PM

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.

### #25d000hg  Members

Posted 09 January 2009 - 09:38 PM

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 :)

### #26ToohrVyk  Members

Posted 09 January 2009 - 10:38 PM

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

### #27samoth  Members

Posted 09 January 2009 - 10:51 PM

Quote:
 Original post by MikeTacularmy boss recently had me make an API change [...]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.Is this normal?
Yes. It is quite common that people who take decisions have no flipping clue what they are talking about. However, they are still the ones who decide.

This is where corporate branding and FUD have their base. It is what influencer marketing aims at too. Big companies have been successful selling inferior goods and services with that strategy for decades.

In other words, executives will rather spend 250,000 for something that works less efficient and has higher maintenance cost than something they could get for free or nearly so based on the fact that some guy they play golf with says it's what people use, or because it has a big name.

It looks like your boss has a great career as executive ahead. :-)

### #28Richy2k  Members

Posted 10 January 2009 - 02:10 AM

Quote:
 Original post by d000hgBut, 33 is nothing.

There is no need for functions like that. Really.

### #29d000hg  Members

Posted 10 January 2009 - 03:23 AM

Quote:
Original post by samoth
Quote:
 Original post by MikeTacularmy boss recently had me make an API change [...]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.Is this normal?
Yes. It is quite common that people who take decisions have no flipping clue what they are talking about. However, they are still the ones who decide.

This is where corporate branding and FUD have their base. It is what influencer marketing aims at too. Big companies have been successful selling inferior goods and services with that strategy for decades.

In other words, executives will rather spend 250,000 for something that works less efficient and has higher maintenance cost than something they could get for free or nearly so based on the fact that some guy they play golf with says it's what people use, or because it has a big name.

It looks like your boss has a great career as executive ahead. :-)
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.

### #30M2tM  Members

Posted 10 January 2009 - 08:50 AM

Yeah, I'm glad this resolved properly into a refactoring of the function into an object. It is exactly the type of thing that shouldn't be a single function.

### #31RivieraKid  Members

Posted 10 January 2009 - 11:15 AM

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

### #32trzy  Members

Posted 10 January 2009 - 01:32 PM

Quote:
 Original post by RivieraKidi 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

### #33benryves  Members

Posted 10 January 2009 - 02:27 PM

Quote:
Original post by trzy
Quote:
 Original post by RivieraKidi 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 +++]

### #34polymorphed  Members

Posted 10 January 2009 - 03:03 PM

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

### #35Way Walker  Members

Posted 10 January 2009 - 03:28 PM

Quote:
 Original post by RivieraKidi 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            );}

### #36trzy  Members

Posted 10 January 2009 - 10:44 PM

Quote:
 Original post by polymorphedWhen 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

### #37Dmytry  Members

Posted 11 January 2009 - 06:49 AM

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]

### #38Cornstalks  Members

Posted 11 January 2009 - 08:36 AM

Quote:
 Original post by ToohrVykI 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 d000hgIt'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.

### #39Rydinare  Members

Posted 11 January 2009 - 08:38 AM

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.

### #40EvilNando  Members

Posted 11 January 2009 - 11:50 AM

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

Thank you sir , never laughed so hard in my life

seriously