Quote:Original post by MikeTacular

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.


There is certainly no performance advantage either way. Depending on how the rest of the API is designed, an information struct (or multiple structs) might make a lot of sense. But I could envision scenarios where it wouldn't be worth the hassle to create a struct (or God forbid, a class) where people would have to take extra care to make sure they initialized every member properly.

Personally, I don't use IDEs very often, so I can't rely on IntelliSense or similar features.

Bottom line up front: 33 parameters for a function means you have a problem

1. Go out right now and buy "Refactoring" by Martin Fowler.
2. Read it over and over again until you understand that 33 parameters is a serious "code stink".
3. Kick your boss in the nuts (optional).

If this is production code that you're working on, that means you will need to maintain it and support (hopefully) many customers using the code. Good luck finding bugs in code where that kind of function call is acceptable. I imagine a customer would not be that happy to use that function either. Just that function alone makes me nervous about the rest of your code base.

Cheers,

Bob

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.

I'd also like to point out that code written by outsourcing companies frequently looks like this too.

They either

A) don't care about the maintainability of the code because they are a one time contract, or

B) intentionally sabotage the maintainability of the code so you'll have to go back to them when you need changes or fixes.