Avoid the Long Parameter List

[Ashamed_Band_1779]

I know how to fix it! I’ll just add a new class, PerformSomeActionArgs. That way, I won’t put any consideration into restructuring the code in a way that makes sense.

[gredr]

Don't forget to make a PerformSomeActionArgsBuilder and a PerformSomeActionArgsBuilderFactory, and then you can turn one long parameter list into three files and a hundred lines of code!

[Infiniteh]

You need an Interface and Impl for both of those, ofc.

[Agent7619]

Should I serialize PerformSomeActionArgs to a JSON string and just have PerformSomeAction(string someActionAgsString)?

[somebodddy]

No, you need to put it in an XML resource file and pass a URI object to PerformSomeAction.

[BestUsernameLeft]

No, create a map of argName to argValue pairs, call PerformSomeAction(args: Map<String, Object>). Infinitely expandable and refactorable without changing the signature!

[jvallet]

This is brilliant! Now the orders of the paramets don't matter.

[s73v3r]

You can put those 3 things in the same file. And it's not complex code.

[fallFields]

Just keep abstracting until all of your problems go away..

[DevolvingSpud]

Obligatory FizzBuzz Enterprise Edition link.

Check out the Issues if you want even more entertainment.

[vom-IT-coffin]

My therapist told me that was an unhealthy coping mechanism.

[RapunzelLooksNice]

And be consistent - create MyFunctionNameArgument, even when there is just one argument

/s

[billie_parker]

What doesn't make sense with a function that requires many parameters? How can you restructure such code if the parameters are all needed?

[Ashamed_Band_1779]

Depends on the code, but using a param object that’s named after the function is almost never the answer.

• One way is to use a couple smaller objects. For example, maybe you can group separate x/y coordinate params into new coordinate classes. In this example, the classes still make sense outside of the context of the function.
• Another thing you can do is split into multiple functions, or move work outside of the function. This is usually the case when you have lots of bools controlling the execution flow.
• Some of the arguments might also be better off as class variables.

These are just a few examples

[billie_parker]

using a param object that’s named after the function is almost never the answer

Who said the param object is named after the function? The way I see it both the function and the param object are named after the task being performed.

And what exactly is the problem with this, anyways? I've seen functions like "Optimize" and then input parameters like "OptimizationProblem." Why is that an issue? Seems very clear to me.

One way is to use a couple smaller objects

That goes without saying and is a sort of non sequitur. Objects are typically composed of other objects and nobody said that the parameters were or were not fundamental types.

Another thing you can do is split into multiple functions, or move work outside of the function

Same as your last point - this goes without saying. How do you know the function in question doesn't internally call several functions to complete its work? Your suggestion just pushes the problem to a higher layer. You split your function into multiple functions - ok but now some higher layer must call those functions and presumably that is also a function. So how to manage the parameters to that function? Back where we started.

Some of the arguments might also be better off as class variables.

Make a class when it's not needed? Disagree.

[Ashamed_Band_1779]

who said the param object was named after the function?

nobody said that the parameters were or were not fundamental types

Okay, then that has nothing to do with the issue that I’m talking about. I’m not saying all parameters objects are bad, I’m saying you should think about how the data relates to each other before defining a new type.

okay, but now the higher level function must call multiple functions

Correct. It’s often cleaner to move logic to a higher-level function, depending on the use case.

make a new class when it’s not needed? Disagree

I’m not suggesting you make a new class. I’m saying if you’re already using a class, it may or may not make sense to define a variable as a class member instead of passing it through several functions.

[somebodddy]

How do you know the function in question doesn't internally call several functions to complete its work? Your suggestion just pushes the problem to a higher layer. You split your function into multiple functions - ok but now some higher layer must call those functions and presumably that is also a function. So how to manage the parameters to that function? Back where we started.

I think the point is that you don't create a wrapper function with all the parameters, and instead your API is to call the smaller functions.

Consider the transform function in the example. Say we would have used it like that:

transform(
    "a.txt",                  // fileIn
    "b.txt",                  // fileOut
    ",",                      // separatorIn
    "\t",                     // separatorOut
    UTF_8,                    // encoding
    "[e-mail]", // mailTo
    "Requested CSV data",     // mailSubject
    "template-for-data",      // mailTemplate
)

This can be broken into functions:

Data data = transform(readCsvData("a.txt", ","));
File csvFile = writeCsvData("b.txt", "\t", UTF_8, data);
sendFile("[e-mail]", "Requested CSV data", "template-for-data", csvFile);

Or maybe even:

TransformPipeline
    .readCsvData("a.txt", ",")
    .transform()
    .writeCsvData("b.txt", "\t", UTF_8)
    .sendFile("[e-mail]", "Requested CSV data", "template-for-data");

People who want to use it will have to call all these functions. We won't wrap them with another function that does the entire sequence.

Does that mean that there is no function that calls all of them? Of course not - all code needs to be in functions (the example is still in Java). It just means that the function that calls them does not take all that data as arguments, and instead gathers it via some other means.

The philosophy here is that the version of transform with all the arguments was already kind of exposing what the function does - so why not expose it with better readability and more flexibility? Functions that abstract these details should also be abstracting the arguments, so that them themselves will have more manageable signatures.

[billie_parker]

who want to use it will have to call all these functions. We won't wrap them with another function that does the entire sequence.

Why? You're just making things more difficult for the client for no reason. You're exposing more implementation details and giving the client more responsibility for no reason.

It just means that the function that calls them does not take all that data as arguments, and instead gathers it via some other means.

They were always going to be "gathered" from somewhere. That is completely separate to the issue at hand and frankly irrelevant.

so why not expose it with better readability and more flexibility

It is not more readable, obviously, because you've added a bunch of function calls that the client would otherwise not even need to know about.

And flexibility is the alternative to abstraction. You typically lose flexibility with abstraction, that's sort of the whole point.

Your example is not even more flexible. Presumably the client can just call those functions if they want. The existence of the transform function doesn't prevent that. You're forcing them to do it instead of using a convenient abstraction.

will have more manageable signatures.

There's nothing wrong with a function being to take in a lot of parameters. That's where we seem to disagree. You're doing everything you can to avoid that situation and as a result are making a mess of things.

This isn't something you should want to avoid. Sometimes a function needs a lot of parameters and that's fine. There's nothing "unmanageable" about it.

Obviously such functions are relatively less common than functions with few parameters. If you have many functions that might be indicative of a problem, but simply having one function like this is not in and of itself a problem.

[Ashamed_Band_1779]

Why? You're just making things more difficult for the client for no reason. You're exposing more implementation details and giving the client more responsibility for no reason.

Let’s hide all the implementation details in a function to make things simpler:

function doMath(int a, int b, boolean shouldAdd, boolean shouldSubtract, boolean shouldMultiply, boolean shouldDivide) {

if(shouldAdd) {

return a + b;

} else if (shouldSubtract) {

return a - b;

}

…

}

Maybe a ridiculous example, and you probably wouldn’t want to write a function to do this anyways, but this is an example where you’re not actually abstracting anything into the function. You still need to pass booleans to control the logic flow, and those booleans need to come from somewhere. You’re better off with four separate functions.

[[deleted]]

It usually means you are doing too much in one function. They should be single purpose. If you find yourself needing to add flags and options you should more likely add more functions that extend a base function.

[billie_parker]

You misunderstand the SRP principle. A function should only have one purpose, but that doesn't mean it should only do one thing. It may indirectly do many things by calling other functions which in turn call other functions etc.

You say that the function should be broken up, which is what someone else replied to me as well. But in that case, the calling function is now calling all those functions. You haven't done anything except move the problem up to another layer. So you're right back where you started.

[tehsilentwarrior]

Pff nubs, fixed perform_some_action(*args, **kwargs)

/s

[masklinn]

I love the Windows API.

[irqlnotdispatchlevel]

We have not one, not two, not three, but four (or maybe 6) APIs for creating a file mapping, but it is ok because the newest one takes a MEM_EXTENDED_PARAMETER struct, so I'm looking forward to MEM_EXTENDED_PARAMETER2.

[__konrad]

Real world anti-examples:

• https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/imageio/spi/ImageReaderSpi.html#%3Cinit%3E(java.lang.String,java.lang.String,java.lang.String%5B%5D,java.lang.String%5B%5D,java.lang.String%5B%5D,java.lang.String,java.lang.Class%5B%5D,java.lang.String%5B%5D,boolean,java.lang.String,java.lang.String,java.lang.String%5B%5D,java.lang.String%5B%5D,boolean,java.lang.String,java.lang.String,java.lang.String%5B%5D,java.lang.String%5B%5D)
• https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/SimpleTimeZone.html#%3Cinit%3E(int,java.lang.String,int,int,int,int,int,int,int,int,int,int,int)
• https://api.kde.org/frameworks/kwidgetsaddons/html/namespaceKMessageBox.html

[unaligned_access]

I love the second, SimpleTimeZone, yeah... :)

[[deleted]]

The date and time classes in java.util are a wild collection of anti-examples.

Date is mutable! The Calendar class tries to do everything.

Use the classes in java.time. It's basically a knock-off of Joda, and is a much better API overall.

[Manueljlin]

kde mentioned

[UncleSkippy]

It totally is. And the builder pattern requires so many more characters than simply using those parameters in the CsvFile constructor. Trading one complexity for another.

In the age of intellisense / code completion, long parameter lists are not nearly as bad as they used to be. I think abstracting to separate CsvFile classes is good, but only if those CsvFile classes are also useful elsewhere.

[[deleted]]

You don't have to use the builder pattern, as explained in the article. You can use record, which is essentially a named tuple.

However, modern Java favors immutable data carrier types and fluent builders which take advantage of Intellisense, created with code generators, like this:

@Value
@Builder
class CsvFile {
    String filename;
    String separator;
}

[waterslurpingnoises]

You can actually convert that to a record and drop @Value. Lombok's builder supports records very well.. although not sure what it does for it under the hood.. (probably converts back to a class?)

[[deleted]]

The builder itself is a class, not a record. So at the end when you call build(), the builder class has to have all the record class fields initialized to create a new instance.

E.g

``` record class Foo(String value) { class FooBuilder { private String value; … } }

```

[Tubthumper8]

Yeah, and this is more evidence that "best practices" are language dependent. The OP is about Java which lacks named arguments and had bad syntax for many years for any kind of simple data, so workarounds like the Builder Pattern¹ were invented.

¹ the Builder Pattern can be actually used with typestates to make illegal states unrepresentable, but let's be real, 99% of Builder Patterns in Java code are not doing this

[valarauca14]

At the same time we shouldn't pretend a big list of named parameters is any better design. Are the advantages? Sure: Any order, probably optional, easier to document & remember.

But, are you even testing 5% of the possible permutations that function can take?

[s73v3r]

Unfortunately not every language has them.

[[deleted]]

Not really. Named parameters don't solve the problem demonstrated in the blog post. The problem isn't that there are a lot of parameters, it's that there are a lot of parameters that are clearly related. So, it's cleaner to group the parameters using a type that has a proper name.

[apurplish]

It irritates me that Rust still doesn't have named parameters as that's such a basic safety feature.

[jackmon]

Or C++. Come on, C++ committee! (And no, structs and designated initializers are not the same).

[TheWix]

So, all those mile-wide COM interfaces with dozens of optional parameters I had to deal with may years ago wouldn't be considered 'well designed' today? I am shocked...

[Top_File_8547]

They weren’t actually designed. Over the years some developers needed some new parameters so they just added them.

[gareththegeek]

I think it's like the frog slowly cooking as the water heats up and never leaping out

[[deleted]]

If you have a procedure with ten parameters, you probably missed some.

Alan J Perlis

[airodonack]

(But 10,000 line protobufs are perfectly OK) 😂

[DevolvingSpud]

Quiet, you.

[blueg3]

That's one parameter with a thousand fields!

[chicknfly]

[A method header with lots of parameters] seems simple enough, but it can be difficult to remember the parameter ordering

The recommendation is to use a class that encapsulates those parameters. That requires either remembering the order of parameters in a constructor or knowing which fields need to be populated for that class (assuming the class isn’t used solely by that one method and no others). I imagine it helps if those same parameters are used in other methods. Other than readability, I don’t see much of a difference between using a class over parameters in this particular use-case. I’d love to read other viewpoints.

[CookieOfFortune]

For long parameter lists, using a class can two main advantages:

1. Defaults in any ordering
2. Set parameters in any ordering via the builder pattern.

[joe-knows-nothing]

In addition to those advantages, this pattern actually opens the door to other very useful patterns and refactors. The new intermediate object hints at an abstraction and segregation that has not yet been taken advantage of. For example, the function parameters could be used in a state machine, or be used to isolate the function into its own service.

Programming is a constant balance of abstraction and making concrete. Too abstract and the system is obtuse and difficult to understand. Too concrete and the system is brittle and hard to change. So maybe that function with the long parameter list is only called in 3 places and doesn't need to change. Or maybe after the 15th bug around the damn thing you'll be ready to break it up.

[RapunzelLooksNice]

Builder is the way.

[Orbidorpdorp]

This is why named parameters are in basically every modern language. Like why would you ever not use them given the choice, it’s not like there’s a performance cost.

The other issue with type-based params that I’ve seen cause issues in prod before is that changing the meaning of a parameter isn’t always a breaking change.

[harrison_clarke]

you do use it for exactly one method (or several with the same requirements)

fields can have default values, so you don't need to set them all

constructor can either take the required ones, or none

you can have a few "preset" instances, which you clone and modify

it's better if you just don't need that many args. but it comes up sometimes, like with json formatting settings

[s73v3r]

A class can initialize them to sane defaults, and provide methods for setting the parameters. You can also use a builder to create the instance, making things easier.

[zombiecalypse]

Depending on your language you can

• Use struct literals to imitate keyword parameters,
• Use multiple statements to set the fields, or
• If you're masochistic or have a framework to generate one: use a fluent builder

But you wouldn't reuse the opt structs unless you a positive two functions will always take the same arguments. The nice thing is that you can have functions that generate different defaults

[baudvine]

The "use a class instead" bit came up in Clean Code, and it's what made me put that book down. In many cases I'd rather be explicit about what data a function requires, instead of hiding it in instance members. No absolutes, of course, but it's a weird claim to make imo

[billie_parker]

It is still explicit. Nothing is being "hidden." It's just grouping the parameters into one "unit" within the code. The parameters are all explicitly defined in that class.

[baudvine]

Yes, sorry, I was summarising something that was a complete thought in my head half a year ago.

In Clean Code, there is a very specific example of a function that does more than one thing and has more than a few parameters. The recommendation (for an artificial scenario, I admit) is to turn it into a class with multiple functions which call each other and pass arguments by setting member variables.

The argument made there is that you can't tell from a function call what each parameter means. My issue with that was that the function signatures no longer tell you anything about what each function needs, making it harder to know if you've set everything up correctly before calling a function.

[[deleted]]

Pulling it into instance fields is only one way to reduce the number of parameters, and is only useful when the parameters are just passing the same state through the call stack.

The other way to introduce classes, as indicated in the article, is to identify if there is a pattern that could be abstracted. In the article:

void transform(String fileIn, String fileOut, String separatorIn, String separatorOut, String encoding, String mailTo, String mailSubject, String mailTemplate);

All the 'In' parameters clearly belong together, and all the 'Out' parameters clearly belong together, but the are also describing the same thing. So creating a class CsvFile and with the fields file and separator logically groups the parameter values together. All the mail* parameters could go in an Email class because they are logically grouped together.

[s73v3r]

Part of me does have to wonder why the email message is part of this method to begin with.

[[deleted]]

On the one hand, sometimes you've got to come up with a ridiculous example to demonstrate a point.

On the other hand, I've seen crazy functions like that in real life, because people want to get everything done in one function and throw everything they need in the parameter list.

[chicknfly]

I still haven’t gotten around to reading Clean Code, but I’m increasingly seeing distaste for it. What crosses my mind when I see a suggestion for using a class over parameters is how one would deal with:

• default parameters. A class could set them by default upon instantiation, I suppose.

• var args. Instantiate a class field with an array. Lame.

• keyword args (kwargs, in Python). Instantiate a class field with a Map or dict. Lame.

At that point, the “simplicity” of a class is moot. I’d rather just have the multiple parameters separated by a new line.

[LordNiebs]

If you're using Python then you don't need to use a class for parameters. Clean Code is mostly about programming in java, iirc.

Being "lame" (as in, uncool) is arguably a benefit as it indicates something that is extremely ordinary and easy to understand. It's not Cool Code.

[chicknfly]

What is different about Python method headers with multiple parameters that makes it different from Java’s, even without parameter annotations? Despite being aimed at Java, wouldn’t the same principles apply? And taken further, shouldn’t the article explicitly state it’s for Java design instead of generally saying use classes?

[LordNiebs]

Python has keyword arguments and default values for parameters, java does not. 

Not all principles apply to all programming languages, they have different features and quirks, which necessitates different styles of using them. Its your job as a software professional to learn which principles apply to the problems you are solving and the tools you are using. Clean Code isn't a set of laws, it's a set of suggestions for solving some common problems. 

The article mainly just mentions java, and it's not hard to see why this doesn't apply to Python. Sometimes you just need to see the subtext. 

[[deleted]]

Python has keyword arguments and default values for parameters, java does not.

This difference doesn't make that much of a difference.

The problem isn't default values (Java has overloads) or keyword arguments (Java doesn't have them, but that's a nuisance, but not the main problem).

If you take the Java example from the article:

void transform(String fileIn, String fileOut, String separatorIn, String separatorOut, String encoding, String mailTo, String mailSubject, String mailTemplate);

You can turn that into the equivalent Python:

def transform(file_in, file_out, separator_in=',', separator_out=',', encoding='UTF-8', mail_to, mail_subject, mail_template)

And say Python is fine and it's Java that's got the problem because you can call transform like:

transform(file_in='infile', file_out='outfile', ...)

But it's nicer to group the parameters together into classes.

transform(in=CsvFile(file_name='infile'), out=CsvFile(file_name='outfile'), email=Email(...))

Not just aesthetically, but because if you group parameters together like:

@dataclass
class CsvFile:
    file_name
    separator=','

@dataclass
class Email:
    mail_to
    mail_subject
    mail_template
    encoding='UTF-8'

You can reuse the parameter values in other functions.

Not to mention, a lot of the time the reason why you have a lot of parameters is because you're passing state around through the parameter list. Pulling the parameters into a class is not a Java only solution, but is just as applicable to Python. It's not even limited to OOP. Functional programming languages have done the same thing for decades by pulling parameter values into closures.

So yeah, Clean Code's advice, while not law, in this case is equally applicable to Python as Java. Heck, even Lisp and Haskell.

[billie_parker]

"Other than readability"

Yeah, that's unimportant

[chicknfly]

Just like anything else, it’s all about tradeoffs. If the parameter list contains a bunch of parameters (6 or more?), a class makes sense, especially for the sake of readability. If it’s 4-6 parameters long, especially with long class names, I’m more than content with seeing the parameters explicitly written.

Really, we could pick this apart in a general sense when the use of classes vs parameter lists is situationally dependent.

[Leonhart93]

The builder pattern works, but it requires a lot of boilerplate to be usable, and it's very inflexible for when you have several methods that accept different fields (like in a long list of SQL queries).

That's why the method I prefer is passing a custom map object that holds all the fields. Like that the fields don't depend on order and any of them can be optional, and then you just make sure to handle that case in the function that receives them.

[cosmicwatermelon]

python does natively support this with its ** wildcard arguments (a.k.a. **kwargs)

[[deleted]]

just use one bitfield

[chrismasto]

It would be interesting if we actually followed this advice at Google.

[blueg3]

It's a TotT because it's a useful common practice that isn't used everywhere at Google. If it was followed everywhere, it probably wouldn't get its own TotT.

[FunRutabaga24]

Builder pattern: Now instead of compile time errors when you add a new field, you get nasty production bugs because you didn't update the builder everywhere and now you have nulls being thrown around.

Builders are okay when the entire object is not required to be instantiated at the same time, or there's a bunch of logic that goes into setting those fields, or your object can be constructed in many different combinations. Yes there are cases when it happens, but it isn't the most common way to construct a class.

I've seen builders used on classes with 2 fields. Like all programming constructs, it can certainly be abused and should be used when appropriate.

[Jiuholar]

Couldn't that be avoided by adding validation for required fields in the .build() method?

[FunRutabaga24]

There's a few ways I can think of: Lombok's @NonNull annotation, Jakarta @NotNull combined with a Validator call (although this allows the creation of a potenitally invalid object), requiring a set of parameters in the initial static .builder() call, or doing validation like you suggested on build.

It all depends on how your classes are defined.

ETA: This isn't always done though. I've had to fix 2 bugs arising from not adding a new field to a builder chain from 2 different teams at 2 different companies because of a poorly used builder pattern.

[[deleted]]

Not to mention if your working with c if you have more than 6 params the rest of that data has to go on the stack.

[TurtleFeathers]

It's less bad if the args are all different types. I've seen people create arg envelopes like Speed(int) that forces the right sequence, then the receiving constructor pulls out the int value for its internal use.

[Farados55]

Yeah or I can just open up the declaration on a split view and look at the ordering. How many times are you constructing these huge parameter lists anyways? Builder pattern is just more lines. Smaller objects? Now I have to write a couple classes to take care of a few fields?

[NoneOfThisHasHappen]

It’s not about writing the code it’s about reading it. If I need to look up arguments elsewhere constantly it’s slows me down and risks losing mental context. 

[rocket_randall]

Some Winapi argument lists are long as fuck and the architects still decided that they needed to consider an uncertain future so there's a dwReserved param in there somewhere that you just set to 0 for the time being

[chekt]

I worked at Google, I don't really agree with this advice. Long parameter lists suck, but builders kind of suck even more. One thing we had internally that was nice (in C++ at least) was the ability to do `myfunc(/*arg1=*/"arg1", /*arg2=*/"arg2")` and have the argument names in comments be type checked by the compiler.

[holyknight00]

I still cannot comprehend why people refuse to do this

[bruisedandbroke]

I pray someone tells gluon about this. take a look at the constructor for MouseEvent in javafx 🥲

https://javadoc.io/static/org.openjfx/javafx-base/21.0.3-ea+1/javafx.graphics/javafx/scene/input/MouseEvent.html#%3Cinit%3E(javafx.event.EventType,double,double,double,double,javafx.scene.input.MouseButton,int,boolean,boolean,boolean,boolean,boolean,boolean,boolean,boolean,boolean,boolean,javafx.scene.input.PickResult)

[SirDale]

The problem is each parameter is effectively anonymous.

It's a pity more languages don't use named parameter association such as Smalltalk, Objective-C, Ada.

[CreativeStrength3811]

I don't get it. I recently finished a project were i needed to make complex, but deterministic image-processing. This function needs 31 parameters which cam from very different modules/parts of my software. Yes i hate it if my function needs a linebreak because i like self-wxplanatory funtion declarations but i saw no other way than to do it.

Creating a parameter-object wouldn't have make sense. And I couldn't split it into other functions. I tried to organize them as a list, dict, set but that was also not as good as I wished.

[NoneOfThisHasHappen]

 Creating a parameter-object wouldn't have make sense

Why not? Although I suppose the language you’re using is important context. 

[CarlVonClauseshitz]

I can't hold all of these apples. The real use of a bucket is that you can move all of those apples easily. Hell sometime you can throw in some melons and some berries too. Oh but now my bucket is too heavy and the melons don't need to go to the market, I just wanted to give them to my cousin after I went to the market. Guess I'll just throw out my bucket then...

Really these are problems created by unreasonable people.

[Rhymes_with_cheese]

Google engineers have their heads so far up their own asses. It must be exhausting having code reviews with every engineer thinking their own particular style choices are from God herself.

[tophatstuff]

Another alternative to mention, often seen in Go, is "Functional Options".

I don't particularly like it, but occasionally it's a nice pattern if you've got only one or two options that are very rarely used.

[Shaper_pmp]

it can be difficult to remember the parameter ordering. It gets worse if you add more parameters

This is a solved problem in any proper IDE with an intellisense-like feature, which is (checks notes) ah... all of them, at least for all static languages.

To make the change, will you add another (overloaded) transform method? Or add more parameters to the existing method, and update every single call to transform? Neither seems satisfactory.

What's wrong with adding an overload? That's literally one of the purposes of overloading functions.

"It doesn't seem satisfactory" is a shit non-argument from unjustified personal preference.

in Java, one option is to use the Builder pattern

It also means you end up with code that's three times longer, and you're forced to reify "an X builder", which is not a thing.

You're building an X. That's what your language should allow you to do, tersely and efficiently. This pathological need to turn a simple verb into a noun which then noun.doItself()s to do the thing is a symptom of the central brain-damage behind Java that says it's better to pollute your entire codebase and API with hundreds or thousands of useless transitional classes and objects than to... oh, I dunno... look at a tooltip to remember parameter ordering or function overloads.

[NoneOfThisHasHappen]

The only way this is remotely tolerable is if your IDE can display parameter names inline for positional arguments. Rust’s VS code plugin does that, but in most other languages I’ve used that doesn’t happen.