Parameter Arrays Are Bad Abstractions

Parameter Arrays are Bad Abstractions

Don’t set a bunch of data in a row like [1, "new", False] and just to pass it to a function and expect it to behave well.

If you’ve ever had to set or unset a bunch of parameters sequentially you’ve probably been tempted to jam it into an array and call it done. Avoiding the dreaded parameter list is noble, but consider that what you are about to do is a terrible idea.

JavaScript and TypeScript actually do a great job of this; they have “objects,” but without all the bloat of most OOP paradigms. If you have a set of parameters or data that needs to be set and move together, you can make anonymous objects and ‘destructure’ them.

const parameters = {
  p1: 120,
  p2: "errors",
  p3: false
};

// ... so on, so forth

someFunction(...parameters);

This is a good idea, and it sucks when other languages don’t have this.

Otherwise, you’ll be setting things like this

parameters = {
  "p1": 120,
  "p2": "errors",
  "p3": False
}

some_function(parameters.p1, parameters.p2, p3=parameters.p3)

Which is still better than the dreaded

some_function(120, "errors", False)
some_function(69, "warn", True)
some_function(111, "fatal", False)

Types

Typed languages are better than untyped, and Python’s version of typing barely counts.

If you’re making serious software, or software that has to do things that your brain can’t easily think about for long periods of time, then you’ll appreciate types. If you’re still thinking that you are some ubermensch, then I’m sure you don’t need AI, or that the LLM will figure it out for you, or that you’ll be able to reason about a million lines of code just fine - it’s a skill issue.

The benefit of typed parameters is that if your type system is even semi-consistent, you can come back to the test, the config, or function-handler-factory your hack manager Bob insisted you write to “clean up,” the code… you can come back to that, poke around at the type definition, and figure out what to do to add a new permutation. And if it doesn’t work, and you’ve got some IDE-like features, you might be able to figure out what other code needs to be changed.

With your parameter list, or array, you need to re-read that code, or that function-handler-factory to figure out where in the OOP hell you were supposed to add a configuration. Not that using typed parameters will banish that demon entirely, but it’s -1 place to watch.

The Magic of Labels

Another quirk of the object destructuring pathway is that your data must be labelled in some way. That’s right, you don’t have to use registers like in MIPS, you can in fact label things.

Now, you may look at my example and point out that my parameters are “p1,” “p2,” and “p3”.

Yup, and that’s not good.

But you know why that might not show up? Because for every object destructure call, there’s this thing called the function which also asks for a set of parameters, and ever since ES6 you can do the same thing on the definition side.

So next time you make a function, maybe try this thing that’s reaching 10 years old.

For other languages that don’t have this (and come on, even Python has this), well have fun.

Don’t use Parameter Arrays

This has been a PSA, and a warning from you future self who unfortunately has to read your code.