That’s why IntelliJ shows you, in these kinds of cases, the names of the parameters where the function is called…

There are also languages, like Scala and Swift, with named parameters, which also solve this problem.

Good IDEs have multiple ways of showing you this info, and many languages have named parameters that fix this. Also, just putting a comment on them is not a crime, it just won’t update when you change the function but then your IDE can often only do so much at call sites, so you often need to update the calls (and the comments) manually. I’m sure LLM agents can change both as well.

Or, in JavaScript like these examples were, yeah, just pass in an object. Passing in an object should be standard in JS when you have more than like 2 params anyway because it solves several issues with parameter identification, optional parsms, method overloading, and so on. And JS passes everything by reference so you aren’t losing performance.

I use keyword arguments in Python to minimize this pain. Instead of

create_user("Bob", True, False)

it’s

create_user(name="Bob", admin=True, send_email=False)

JavaScript makes that more cumbersome with the object thing , but it’s better than nothing.

TrainBuilder::new()
  .with_electric_motor(true)
  .with_width(1.0)
  .build()

doWork(.{
    .flurbify = true,
    .flurbification_intensity = 1001,
});

TypeScript doesn’t really save this

TypeScript tells me the values are booleans. That’s not really the problem.

The types are technically correct. I still have to remember what the arguments mean.

You could use branded/tagged types. Probably not useful in these narrow, one-off occurrences. But if you have a concept that applies across your whole domain, they can be useful.

Agree with several people here that named parameters are a good solution, they add minimal overhead at the call site and function declaration and look very natural.

Another option for languages that want function arguments to have fixed size is bitmasks. I wonder if it could be a useful language feature to infer the flag names from the function declaration. Something like

def my_function(arg1, arg2, [FLAG1, FLAG2]) {
    if (FLAG1) {
        do thing
    } 
   ...
}

my_function(val1, val2, FLAG1 | FLAG2)

Yup, I’ve taken to doing this exact same thing in TS/JS. That is, defining functions to take an options object instead of multiple parameters.

It’d be much nicer if TS/JS could support named parameter binding, like many other lanaguages, cause that’s what I do as a nearly universal rule, in every language that supports it.

No, having an IDE inject paramter names in the editor is not a solution. Not only does it always look like shit, because none of them have any concept of formatting for readability, it also means the code then becomes unreadable outside of an IDE (and user configuration) with that feature.

Opinion: if the method takes a boolean it should be split to two methods. If it takes two bools it’s four methods in a trench-coat.