• 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 ;-)

  • (nodebb)

    If you can't figure out how to fix that method or why you should split it into one or several classes, I suggest trying to do some architecture. I bet you'll not just find sensible objects to work with but realize there are rules and checks you'd like to do, e.g. when creating the object or setting its values. But I guess everybody does JavaScript today, so maybe I'm way too complex here...

  • (nodebb) in reply to Erik

    https://www.geeksforgeeks.org/repository-design-pattern/

  • Jonathan (unregistered)

    C# supports named arguments which would have made this situation better: https://learn.microsoft.com/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments#named-arguments

  • Duston (unregistered)

    "Clearly the best solution is one single string parameter that contains a comma-separated list of values." Not Enterprise-y enough...it has to be XML

  • Officer Johnny Holzkopf (unregistered) in reply to Álvaro González

    A comma-separated list would be prone to "off by 1" errors, but as you're already operating on stringly-typed data, you could do something like this: updateTheThing(thing, "foo=100, bar=qualified, docClass=doctorToilet, paula=brillant, firstMove=notPlay, sendContractPdf=FILE_NOT_FOUND"); This allows you to perform a "full initialization" by using all parameters, in any order you like, or only a change of one, two, three (or how many you need) parameters. Split by ",", split by "=", use key-value addressing, and throw a technical exception if needed.

  • (nodebb)
    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.

    This would be "something like 6 functions with 6 parameters each". You aren't reducing the number of parameters, you're just splitting them into groups. Maybe there are groupings that make sense, but that's still only an incremental improvement.

    Builder pattern?

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

    Chaining 36 method calls is cleaner? That's a strong no from me.

    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.

    Defining a dictionary with 36 items isn't really any better than having 36 parameters.

  • (nodebb)

    My head hurts after doing my CS:APP midterms that involves a lot of manually reading stack frames.

    For the sake of Computer Science students, please do not pass more than 6 arguments in x86-64.

  • (nodebb) in reply to LilyWhite

    Ha, don't take this the wrong way, but if you don't like reading code, you might have picked the wrong profession. What you experience in school is usually the super soft student friendly simple version of what you engage with in the wilds outside of the protected academic garden.

  • (I wanna be) a European Man (unregistered) in reply to Dragnslcr

    haha glad you're not on my team Dragnslcr - you wouldn't last very long at all. Sound very much like the wanna-be architects I have had to deal with over the years and had to clean up afterwards.

  • (nodebb) in reply to (I wanna be) a European Man

    Considering your response is basically just "Haha, you suck", I'm also glad I'm not on your team. I prefer working with people who know something about software engineering.

  • random dev (unregistered)

    in c# the proper way to do this is to create stupid wide classes is top split into a record with required parameters. I.e. public record TestClass { public required string RequiredParam1 {get;set;} public string OptionalParam1 {get;set;} = "default value"; }

    Separate your poco class and your code class. Pass record in as parameter. Makes unit testing easier too.

  • SyntaxError (unregistered)

    It would be hilarious if Dragnslcr and (I wanna be) a European Man were actually on the same team, both commenting on this article unbeknownst to themselves.

  • (nodebb) in reply to SyntaxError

    Yup, it would be, especially since I'm generally in charge of writing software for the projects I work on, so they would in fact be my teams.

  • Craig (unregistered) in reply to MaxiTB

    Reading stack frames != reading code

Leave a comment on “One More Parameter, Bro”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article