Jump to content

  • Log In with Google      Sign In   
  • Create Account


33 parameters for a function?! Seriously!?

  • You cannot reply to this topic
56 replies to this topic

#21 KulSeran   Members   -  Reputation: 2154

Like
0Likes
Like

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 = {...}
syntax instead of
classA foo(...);

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


Sponsor:

#22 Benjamin Heath   Members   -  Reputation: 925

Like
0Likes
Like

Posted 09 January 2009 - 08:20 PM

Quote:
Original post by KulSeran
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 = {...}
syntax instead of
classA 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?

#23 sergamer1   Members   -  Reputation: 174

Like
0Likes
Like

Posted 09 January 2009 - 08:56 PM

Quote:
Original post by Way Walker
Quote:
Original post by polymorphed
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]


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

#24 Lendichado_   Members   -  Reputation: 143

Like
1Likes
Like

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.


#25 d000hg   Members   -  Reputation: 688

Like
0Likes
Like

Posted 09 January 2009 - 09:38 PM

Quote:
Original post by polymorphed
Quote:
Original post by d000hg
But, 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 :)



#26 ToohrVyk   Members   -  Reputation: 1587

Like
0Likes
Like

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.

#27 samoth   Crossbones+   -  Reputation: 4468

Like
1Likes
Like

Posted 09 January 2009 - 10:51 PM

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

#28 Richy2k   Members   -  Reputation: 313

Like
0Likes
Like

Posted 10 January 2009 - 02:10 AM

Quote:
Original post by d000hg
But, 33 is nothing.


There is no need for functions like that. Really.
Adventures of a Pro & Hobby Games Programmer - http://neilo-gd.blogspot.com/Twitter - http://twitter.com/neilogd

#29 d000hg   Members   -  Reputation: 688

Like
1Likes
Like

Posted 10 January 2009 - 03:23 AM

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



#30 M2tM   Members   -  Reputation: 948

Like
0Likes
Like

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.

#31 RivieraKid   Members   -  Reputation: 363

Like
0Likes
Like

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.

#32 trzy   Members   -  Reputation: 100

Like
-1Likes
Like

Posted 10 January 2009 - 01: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




#33 benryves   GDNet+   -  Reputation: 1992

Like
0Likes
Like

Posted 10 January 2009 - 02: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 +++]

#34 polymorphed   Members   -  Reputation: 272

Like
0Likes
Like

Posted 10 January 2009 - 03: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.

#35 Way Walker   Members   -  Reputation: 744

Like
0Likes
Like

Posted 10 January 2009 - 03: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
);
}



#36 trzy   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 January 2009 - 10:44 PM

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

#37 Dmytry   Members   -  Reputation: 1147

Like
0Likes
Like

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]

#38 Cornstalks   Crossbones+   -  Reputation: 6966

Like
0Likes
Like

Posted 11 January 2009 - 08:36 AM

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.

#39 Rydinare   Members   -  Reputation: 486

Like
1Likes
Like

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.

#40 EvilNando   Members   -  Reputation: 92

Like
0Likes
Like

Posted 11 January 2009 - 11:50 AM

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





PARTNERS