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]

Coding Horrors Community

Started by Cornstalks January 09, 2009 03:39 PM

54 comments, last by Krohm 10 years, 10 months ago

Nytegard

842

January 13, 2009 12:00 PM

Quote:Original post by d000hg
"Crap programmers write crap code all the time" isn't an excuse. Many people out there have no good skills and just throw out anything that works. It's true you can go overboard on the computer science part but this is something quite trivial, if it wasn't for the multiple API issue I'd expect any decent coder to make this change without thinking they need to discuss it. Any professional coder should be automatically writing reasonable code to start with, of course it often won't be perfect but there are degrees of quality and anyone who likes to think themselves a programmer (rather than someone who hacks code) should be a few rungs higher up the ladder!

I never said it was an excuse, only that those types of programmers do exist, and are more common than what we'd like to believe. I'd also have to state towards Mithrandir's post about outsourcing, I don't think it's that they're sabotaging code, rather, software development is a business, and as such, they train people as quickly as possible to come up with working code. And quick learning != proper learning.

Gage64

1,235

January 13, 2009 12:49 PM

Quote:Original post by trzy
Is this,

*** Source Snippet Removed ***

really any better than

*** Source Snippet Removed ***

?

I think it's much better. If you add/remove/change some of the parameters, with the second approach you have to change all calls to that function. With the first approach, you just update the struct. The function calls stay the same.

EDIT: Accidentally swapped "first" and "second".

[Edited by - Gage64 on January 13, 2009 1:49:31 PM]

OOP Articles | C++: A Dialog (free book) | Thinking in C++ (free book) | Google Books - Free preview for many books

Mithrandir

607

January 13, 2009 01:42 PM

Quote:Original post by trzy
Is this,

*** Source Snippet Removed ***

really any better than

*** Source Snippet Removed ***

Yes, it is.

1) You are no longer required to create multiple overloads for differing function signatures for the same functionality
2) Your structure can easily supply default values for languages that don't support default parameters (which are ugly anyways, and prone to break in modern JIT languages)
3) It enhances readability so you no longer have to wonder why parameter 27 is a boolean (I'm certain you've had at least one "wtf does 'true, false, 10, true' mean?" moment before; everyone does).
4) Maybe not too relevant to game programming, but it makes your application service-friendly, since services work on a message digest paradigm. Ever have to wrap an old 5-billion parameter API into a service layer? I have. I wish they used parameter objects instead.

This is my signature. There are many like it, but this one is mine. My signature is my best friend. It is my life. I must master it as I must master my life. My signature, without me, is useless. Without my signature, I am useless.

Mithrandir

607

January 13, 2009 01:53 PM

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!

I'm not looking forward to optional parameters at all, actually.

In .NET, they're implemented entirely on the client side. Say you have assembly Server, which has a function:

public class ServerClass{    public void Function( [Optional][DefaultParameterValue(30)] int a )    {        // do something    }}

Ok now you have assembly Client, which has a function:

ServerClass sc = new ServerClass();sc.Function(); // do not pass in 'a', use default value.

Hit compile, the compiler analyzes Server.Function, retrieves the "30" default value, and injects it into the client IL so that it's literally passing in the number 30.

Later on, you update the server and change the default value to 40, but you fail to update the client assembly as well (very easy to do in .NET, as it was designed to be so modular; easiest situation is when Server and Client aren't even made by the same company). What happens when the client is run?

It will still use "30" as the default value.

Optional parameters are very dangerous in .NET for this reason, and in fact this was the reason they were never implemented in the first place. In my draft of our 2009 code standards, I have completely banned their use in all publicly visible functions (theoretically internal, protected, and private should be safe, but we'll see).

Ravyne

14,306

June 18, 2013 03:10 AM

Old thread is old. Let's not raise the dead.

[edit] the necromancer has deleted his post :/ BTW, he appears to be the same fellow as GoofProf.F, and both accounts have been deleted (banned?) -- As far as I can tell, he's either just here to troll, or has a raging case of Digital Aspergers.

throw table_exception("(? ???)? ? ???");

Cornstalks

7,033

Author

June 18, 2013 03:24 AM

Seriously, this thread is so old people are quoting me as "MikeTacular"...

Edit: And now it looks like Ravyne is the necromancer...

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