Monday, November 19, 2007

Why Are Named Parameters Rare?

One of the things that seems common to most languages, even the supposedly better new ones, is the lack of "named parameters". Surely it must have come to the attention of most language designers that having a line like the following is ridiculous:-

// Do some stuff
int x = MyFunction(true, false, true, true);

Okay, it's probably bad programming practise to have something like this, but even a simpler line with just one boolean would be bad. What on earth does each parameter mean? The only way of finding out is to query the underlying function's code, but that defeats the object of having well named functions. I'm still surprised that having named parameters isn't in most modern languages. How much better is the next line:=

int x = MyFunction(foo:true, bar:false);

Here you can see, without having to browse the underlying function, what each parameter means. Okay, this is nothing earth-shattering that will lead to perfect code, but it has to be a step in the right direction.

4 comments:

ghoulsblade said...

hmm, while named parameters look nice, they make the code longer, so they are more work to type and you loose overview,
so while i see the problem, i don't see them as a good solution.

i think an intelligent IDE, that displays calltipps on mouseover and while typing the function call, is a better solution for this problem, as it does not require extra typing and keeps to code short.

Steve said...

Would a better solution (if no IDE is available) be to reduce the number of parameters to the function, but write multiple functions that call each other with modifiers (if you see what I mean)?

[contrived] example:

function doSumToVar(var, sumtype, amt) {
if (sumtype = "add") {
var += amt;
} ..
}

function incVar(var) {
call doSumToVar(var, "add", 10)
}

[..and lots of other variations]

Then the caller can just choose the function that suits them best.

ghoulsblade said...

while i don't fully understand what you mean, but i understand it as an ironic response to my argument that keeping code short is good for better overview.
Please correct me if i'm wrong.

Longer code that is easier to read also has advantages, especially in situations with large teams (many people with different skill-levels) and a clearly planned design as in big applications, where getting an overview by reading the code isn't meant to be the good way.

But in hobby-gamedev i more often see small teams working on the core code and often rewriting sections, where i think it is important to be able to get an overview over what is happening by scrolling through the code.
At least that is my impression of the few hobby-gamedev projects that i've looked into, it might be totally different in other projects and in professional gamedev.

Anyways : the statement "if no IDE is available" is scary, would you really design a programming language with the main goal of being usable in any texteditor ?

Steve said...

I wasn't being ironic, I was just proposing a solution to having too many function params where a decent IDE isn't available.

It's funny you should mention about "designing a language", since that is what my original post stemmed from: I'm in the process of writing a new language, which I'll blog about soon (once I get a clue about how to do it properly).