• Advertisement
Sign in to follow this  

33 parameters for a function?! Seriously!?

This topic is 1681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


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

Share this post


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

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!


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

Share this post


Link to post
Share on other sites

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.

Edited by Ravyne

Share this post


Link to post
Share on other sites

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

 

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

Edited by Cornstalks

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement