Quote:Original post by MikeTacular
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)?
At my last company our entire product was littered with this stuff.
We actually had a family of over 40 function overloads which all ended up calling the same function in the end, and that one function took over 70 parameters. I think the average parameters per overload was somewhere around 50 or so, and each one was just various combinations of those 70 parameters.
This arose because of the sloppy management style they had. There were no code reviews, and developers were literally treated like assembly line workers. When I finally left, we had 20 unpaid interns and 9 full time developers. The devs were encouraged to imitate previous issues rather than fully understand the code.
So every time a function needed another option, they would get an intern to just add a new parameter or two to the existing code, and be done with it. Refactoring was considered wasteful and time-consuming.
Right before I left I laid out a new architecture (as I was eventually promoted to lead architect) for them to use that would avoid all this, but I was told that what they have already works, so they didn't see the point in going over the the new system.
Just one of millions of reasons why I left.
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.