Hacker News Reader

Comment by TorKlingberg | Hacker News Reader

> Don't use boolean parameters to toggle behaviour - they're indecipherable from the calling context

This is mostly solved in languages with named parameter calling (if you use it). Example: createFile(name, contents, temporary=True)

Sometimes it is already obvious enough. In C I have no problem with set_visible(item, true);

View on HN

You can mimic this in most languages: createFile(name, contents, /* temporary= */ true). Of course that doesn't guarantee that that's what that parameter is actually named, but you can write a lint for that (with quite a bit of effort).

> Of course that doesn't guarantee that that's what that parameter is actually named

I’ve found the odds of that happening approach certainty once you have more than one or two parameters. If you’re using a language without named arguments I usually treat adding a third parameter as a cue to reconsider using a more idiomatic interface, whether that’s something like classic Java OOP (.setTemporary(true)) or limiting that knowledge to one place by e.g. creating a subclass, struct, or a specialized function so you call createTemporaryFile() and know that ordering check only needs to be done in one place rather than by every caller.

I'm not sure about this, because it's easy to mix up two arguments of the same type.

For example, you could mean

    createFile(name, contents, /* temporary= */ true, /* overwrite= */ true)

but write

    createFile(name, contents, /* overwrite= */ true, /* temporary= */ true)

by accident.

Now I want to see something like Prettier (a code formatter that enforces _exact_ whitespace and specific optional syntax) that will parse C code and fill in the correct parameter names, in comments, based on the headers, for any boolean parameters (maybe excluding single boolean parameters?).

A decent linter checks those Boolean comments for accuracy.

Writing documentation that that merely copies existing code is terrible: it's either going to be wrong (because it's not automatically checked and will go sour in a refactoring, or it's right because it's so obvious that no one will guess wrong when looking at it.)

Even something like

    int temporary = true;
    create_file(path, contents, temporary);

In some languages you can use the named-parameter version to indicate what's being true-ified:

  create_file(path, contents, temporary:=true);

C++ has named parameters, too. If you want it to.

Would like an example; this is hardly "solved" in C++. There is an old Boost library that does this, but it's not idiomatic and rarely used.

Unless you are using a different definition of named parameters, I've never seen C++ code in the wild that used them.

That’s a bold statement, I’d love to see an example to show this.

Sounds like the "named parameter idiom", the function comes with a struct that contains all the possible parameters and the caller passes one of those to the function instead of each parameter seperately.

http://www.cs.technion.ac.il/users/yechiel/c++-faq/named-par...

Reply on news.ycombinator.com