[2005] Is this considered bad programming?
I have a method that has over 20 arguments being passed to it. Recently, I was told by someone that this is considered bad programming. He says I should be passing in a object.
Now, if the answer is yes. I have two forms that call this method. One just passes default data to it (resetting values) and the other is passing in Actual Datarow Columns.
I would like to just pass in a Datarow, but it seems that you cannot do:
Code:
Dim row as new row
row("Column1")="something"
row("Column2")="something"
Re: [2005] Is this considered bad programming?
You can not create a datarow from out of no where like that. You have to call datatable.NewRow method. Having said that, you need to create a datatable, add appropriate columns to it. You then can call the datatable.NewRow function to get a datarow object with the same schema as the datatable that creates it.
Re: [2005] Is this considered bad programming?
Quote:
Originally Posted by stanav
You can not create a datarow from out of no where like that. You have to call datatable.NewRow method. Having said that, you need to create a datatable, add appropriate columns to it. You then can call the datatable.NewRow function to get a datarow object with the same schema as the datatable that creates it.
Yeah, I already have a datatable with the schema.
All this method really does is change a whole lot of values in my XML Configuration file.
So I may have to evaluate how this method is even being used.
I may just get rid of the method and inside the methods that call it, just initialize the XML in those methods, but of course I would have to call this method N times.
Re: [2005] Is this considered bad programming?
I would favor the N calls to a smaller function. Alternatively, I might overload the method to take different numbers or types of arguments. If you have the datatable schema already, you can get a new row with datatable.NewRow, and make a version of the method that takes that. Note that NewRow just returns a new row with the datatable schema, it doesn't add it to the table, so it would be a useful way to pass things around.
You might also have an alternative implementation of the method that takes nothing, since you mentioned that one of the forms calls the method with all default values.
I don't think there is anything technically wrong with passing that many arguments, but it would be a very busy method to try to diagnose, especially since many of the arguments probably have the same type, so getting the right value in the right argument could be problematic. All those arguments get passed onto the stack for the function call, but memory is rarely a limitting factor these days, so pushing all those values might incurr some time overhead, but it won't be noticeable.
Re: [2005] Is this considered bad programming?
The industry standard is roughly a maximum of 6 parameters in the method signature. If you go over that, create a class that holds all the values (in properties) instead and pass that single object thru. Or you go that DataTable way, too.
Re: [2005] Is this considered bad programming?
Thanks for the responses and anticipating what some my questions would be.
That method was very difficult to debug because if you sent an empty string value into a parameter that was declared an integer, it would throw an exception. So you could not even step into the method at that point.