3 ms·
> Second, what if parameter blocks were abstractable? Sounds like a great way to make unreadable code #define STANDARD_EXP_PARAMS ... // I hit gotod
by duped 4y ago
> Second, what if parameter blocks were abstractable?
Sounds like a great way to make unreadable code
#define STANDARD_EXP_PARAMS ...
// I hit gotodef on func(...) and got here. What are the arguments?
void func (STANDARD_EXP_PARAMS) {
// ... long function body ...
x = y; // What is the type of x? Is it an argument or a local?
}
I'd really be irritated if someone ever used this feature, optimizing for lines written is shaky territory to begin with. When it's at an interface boundary it's not excusable. NB4 "use an IDE" - requiring an IDE to make code legible is dumb, and I'm an IDE shill!
- robertlagrant 4y agoYou could say the same about a function call or a function that takes an object as an argument - who knows what code lies behind the impenetrable barrier of structured or object oriented programming?
- duped 4y agoThat's actually a feature of encapsulation. The object (ideally) is used to abstract away those details so I don't need to know about them, only how to create the object. Encapsulation is a different feature than reuse. The exception is in languages that use that syntax as a way to implement keyword arguments, but I would still ask people to destructure it in the parameter list or at the top of the function so I can see what the arguments are. The point is that when I am looking at a function definition I need to know how to call it. As described all I see is obfuscation to save some keystrokes, not clean code.
- robertlagrant 4y agoBut how would you know how to call it if it takes an object as an argument? How different would the process be for looking at a named standard set of arguments?