• LongTimeLurker (unregistered)

    FIFY

    public int saveQualif(frist, ....) throws throws TechnicalException, DfException, WTFException
  • (nodebb)

    Refactoring is a problem for tomorrow's developer.

    And, just like tomorrow, it never comes.

  • (nodebb)

    Luckily the amount of method arguments in .NET is limited. But yes, I have also seen methods like this in the wild :-)

    For those interested, the theoretical limit is 65535 arguments; however you will not be able to call a method like that because the stack frame is also limited per method call - so you can only use 2000-8000 arguments depending on type and platform architecture.

    Addendum 2024-11-07 13:53: BTW in C# you can use readonly value types which will end up in basically the same machine code without any allocations:

    public readonly struct Args
{
    public readonly int A1;
    public readonly long A2;
    public readonly string A3;
}

public class Program
{
    public void M1(int a1, long a2, string a3) 
    { 
        Console.Write(a1);
        Console.Write(a2);
        Console.Write(a3);
    }

    public void M2(Args args) 
    { 
        Console.Write(args.A1);
        Console.Write(args.A2);
        Console.Write(args.A3);
    }
}
  • (nodebb)

    I know this is ugly, but is there anything that would completely eliminate the ugly? If you have 36 pieces of information for an object, at some point you have to pass 36 values into the object. I don't think having 36 separate functions is much better, and trying to split the difference with something like 6 functions with 6 parameters each would be an even bigger WTF.

  • (nodebb) in reply to Dragnslcr

    You'd rework to use OOP principles, such as encapsulation with structs/classes. You shouldn't need to pass 36 parameters; Probably only two or three that would contain the other information.

  • LZ79LRU (unregistered) in reply to colejohnson66

    So your solution to having a method with many parameters is to create a bunch of DTO classes that only serve to make the method signature shorter but complicate the calling code. Honestly I would not call that a win. It's just piling on complexity to make things look more to your taste.

  • (nodebb) in reply to Dragnslcr

    but is there anything that would completely eliminate the ugly?

    Builder pattern?

    Qualif.Create() .SetDocClass("value") .SetTradeId("value") .Insert();

  • (nodebb)

    The builder pattern is far better, since you only touch the specific fields. Patterns like that are much easier to test, write and adding a new one is trivial. Database fields should be updated in a typed fashion, unless of course the (not shown) database is all varchar(256)!

  • Conradus (unregistered) in reply to Dragnslcr

    You're trying to do the wrong thing better. Pass it two fields: Thing to change (ideally, this should be an enum of the fields), what to change it to.

    For times when you do need to change the whole record, define a record with all the fields. Pass that.

  • Hasseman (unregistered)

    Fixing problems in a SCRUM (SCRotUM?) environment means it will never be fixed in a proper way. Quick fixes are the norm

  • (nodebb) in reply to Hasseman

    Another reason Scrum/Agile is dogshit.

  • TS (unregistered)

    The minimal first step would be default values and named parameters, unless you're using a broken language that doesn't support them. That would at least give you chance of finding bugs such as int nbUpdates = incoming.saveQualif(docClass, null, null, null, null, multiDeal, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null);

  • Ex-Java dev (unregistered)

    To me, this cries out for getting passed a map. Key/value pairs would work wonders. I initially thought string keys, but I think I agree with Conradus that an enum would be better.

    It'd probably simplify the underlying code, too. Loop through the map, constructing the structured query and value array in parallel. Not the (I assume) pages of if clauses that the method signature suggests.

  • (nodebb)

    So your solution to having a method with many parameters is to create a bunch of DTO classes that only serve to make the method signature shorter but complicate the calling code. Honestly I would not call that a win. It's just piling on complexity to make things look more to your taste.

    The parameter values come from a form. The form can store the values in the widgets directly into members of a business logic data structure that the form controls. I believe that would be simpler.

    As to the second call, I'm not sure. Needs more context.

  • Steve (not that one) (unregistered) in reply to MaxiTB

    "so you can only use 2000-8000 arguments depending on type and platform architecture."

    I do not want to know just how you discovered this.

  • (nodebb) in reply to Steve (not that one)

    Ha, like a dev. I wrote a simple console up that generated me the file and then I tried powers of two after 65535 didn't work :-)

  • Álvaro González (github)

    Clearly the best solution is one single string parameter that contains a comma-separated list of values.

  • (nodebb) in reply to Hasseman

    This is nonsense. One of the few rules of SCRUM is that a user story has to be finished before you can work on another (that's called commitment). So if you reopen a story a bug or do a "bug" story, the workflow is pretty clear, this story has always priority. If you don't do that, you are doing not only SCRUM but all agile development methods wrong cause that's one thing all of them have in common ;-)

Leave a comment on “One More Parameter, Bro”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article