53 replies to this topic

[trzy]

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.

[Scourage]

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

[d000hg]

Quote:

Original post by MikeTacular 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.

Nope not aimed at anyone in particular, just a response to the "bosses are no use if they aren't great programmers" school of thought. Even a boss who was once a full-time programmer can't help but fall behind as he spends less and less time working on software development though, which is what normally happens - and this is doesn't mean he's no longer able to be a good boss.

[d000hg]

Quote:

Original post by trzy 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.

You can set defaults if you have a class, or you can have a solution where you get an error trying to use an uninitialized object.

However, the simple struct approach is very prevalent in Java web applications, where these utility classes are called Java Beans... basically classes with only simple setter/getter methods. They are often mapped to databases and provide a convenient way to pass data around.

[Zahlman]

A useful technique for this sort of thing.

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.

LOL... ?

Quote:

Original post by Benjamin Heath o_O For purely educational purposes, why would you do such a thing?

At a guess, because adding even a user-defined default constructor to a struct makes it no longer qualify as POD per the Standard (I consider this kind of a WTF in itself - of course C doesn't have these options, but there's no reason they ought to have any power to impact the memory layout), and POD-ness is useful for interacting with some older code, doing pointer hackery (especially with I/O), etc.

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.

I don't think this is what actually happens. More likely, people think their bosses harbour dangerous delusions about their technical expertise, and are frustrated that said bosses are unwilling to defer technical decisions to people who were hired specifically for that expertise.

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.

But if you don't already have the object, a reference/pointer to which you would like to pass, then you'll have to construct it, and thus put the data on the stack anyway. The complexity has to go somewhere.

[curtmax_0]

Quote:

Original post by RivieraKid i dont even think stuffing 33 parameters into a struct/class is a good solution. What a mess.

Well, 33 might be a bit much, but some functions do need alot of information. D3D does this very often. Functions take structs with data in them (in addition to other parameters). If all the data were in function parameters it'd be something like 80 parameters or such!

The structs also 'sort of' emulate named parameters because you can leave ones blank you don't care about.

Quote:

Original post by Zahlman A useful technique for this sort of thing.

Very interesting. Seems like alot of setup just to do that though.

[Nytegard]

As much as many of you are laughing at why anyone would use a 33 parameter function, honestly, it's one of the more sain pieces of programming I've seen. Sadly, university tends to teach more of a theoretical approach, and not a realistic approach, and reality tends to be that even professional companies have code that's garbage at best. I've seen functions with over 1000 parameters, I've seen a function which converts a function to a string to be converted to an int, etc. And sadly, this isn't at just one company, and nor is it just a random programmer. Some of the worst code I've seen that could even make it to thedailywtf has come from people who've graduated from Stanford, MIT, and Carnegie Mellon.

Sadly, in almost every job I've ever been in, the idea has been more that "If it works, you can always refactor it later when you have time, but get the next thing out today." Today means adding to the mess, and you'll never have a later in which you can fix what should have never been written in the first place.

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

[Mithrandir]

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.

[Mithrandir]

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.

[Nytegard]

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]

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]

[Mithrandir]

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.

[Mithrandir]

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