3 ms·

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 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.

JetSpiegel 12y ago
If you are writing in C, cryptic and unnecessary truncation is half the fun!
clarry 12y ago
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).
userbinator 12y ago
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.)
- nitrogen 12y ago
  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);
dllthomas 12y ago
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.

JetSpiegel 12y ago

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

clarry 12y ago

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).

userbinator 12y ago

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.)

nitrogen 12y ago
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);

dllthomas 12y ago

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.