Hacker News Reader

Comment by abcd_f | Hacker News Reader

Clever, but seems like a solution in a search of a problem.

The problem is that arguments are often ambiguous without the accompanying function declaration. (And the problem's exasperated when there are lots of arguments.)

The solution is named arguments, but I'm not convinced the added complexity of this solution is a net improvement.

If you are writing in C, cryptic and unnecessary truncation is half the fun!

Maybe there are some situations in which named arguments could be a genuine improvement, but I think in general it just encourages sloppiness and unneeded verbosity. It encourages writing functions that needlessly take way too many parameters (can't you instead think of a way to simplify the problem?). It encourages calling functions without paying attention to all the parameters, which you usually shouldn't ever ignore. Just like you shouldn't arbitrarily ignore return values. If you don't know your function like the back of your hand, you need documentation. Of course, documentation might be sparse in sloppy code that encourages people to ignore the details...

C is like that really. You really need to pay attention to detail when you're writing C. And if there's too much to worry about, it means you need to redesign and simplify the APIs and/or data you're dealing with.

If I encounter functions with lots of parameters in third party libraries I have to use, I will annotate each argument with a comment (after checking the documentation).

When writing in C, usually you either know the function well enough (including having just written it) to have memorised the arguments, have another window containing the declarations, or else you'll be using an IDE that tells you what the arguments are (along with a lot of other information.)

The most frustrating thing in C or C++ is when a header file is missing all of the argument names, so the declarations are just

    OVERKILL_TYPEDEF_PTR_T somefunc(TYPE1_T, TYPE2_PTR_T, void *);

I always document my functions in the headers, especially for private code only I will use. E.g.

    /*
     * Like vfprintf(), but prepends a timestamp and the name of the current thread
     * or process.  The output FILE will be locked using lockf() while the
     * timestamp, thread name, and message are written.  The thread name can be set
     * using set_threadname().
     */
    int vfptmf(FILE *out, const char *format, va_list args);

I find this problem exacerbated by using a lot of primitive types, and ameliorated (though not eliminated) by wrapping things in context-specific single element structs.

Given:

    int price, quantity;

compare

    place_order(price, quantity);

with

    {
        price_t px = { price };
        quantity_t qx = { quantity };

        place_order(qx, px);
    }

More verbose (especially where, like above, the values weren't already wrapped), but catches a significant error.

It does not permit reordering arguments like the struct approach does, and doesn't help where you have multiple arguments of the same type that it is unreasonable to distinguish.

Reply on news.ycombinator.com