• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Cornstalks

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 this post


Link to post
Share on other sites
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]
1

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by benryves
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!
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 this post


Link to post
Share on other sites
Quote:
Original post by janta
For 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 this post


Link to post
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 this post


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


Oh come on! LOL!
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MikeTacular
He 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 this post


Link to post
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 this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by d000hg
But, 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 this post


Link to post
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!

[edit]

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

Share this post


Link to post
Share on other sites
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.
0

Share this post


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

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

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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 :-)
0

Share this post


Link to post
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 this post


Link to post
Share on other sites
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 :)

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0