2 ms·
Because most people can figure out that: CreateProcess(NULL,cmd,NULL,NULL,TRUE,CREATE_NO_WINDOW,NULL,NULL,&si,&pi); is a terrible interface that we should t
by a1369209993 6y ago
Because most people can figure out that:
CreateProcess(NULL,cmd,NULL,NULL,TRUE,CREATE_NO_WINDOW,NULL,NULL,&si,&pi);
is a terrible interface that we should try to split up better, but
CreateProcess(
lpApplicationName: NULL,
lpCommandLine: cmd,
lpProcessAttributes: NULL,
lpThreadAttributes: NULL,
bInheritHandles: TRUE,
dwCreationFlags: CREATE_NO_WINDOW,
lpEnvironment: NULL,
lpCurrentDirectory: NULL,
lpStartupInfo: &si,
lpProcessInfo: &pi,
);
tends not to attract the same scrutiny for some reason. On the other hand, removing named parameters doesn't actually fix this (see jasode's example at https://news.ycombinator.com/item?id=24401913 https://news.ycombinator.com/item?id=24401913 so I don't need another dozen lines), so it's not clear that this is a good argument against named parameters.
- bfrydl 6y agoIn my opinion, the first is a terrible interface because I have no idea what any of the parameters do, not because there are so many. The second is a good interface to me because all of the values are labeled. I don't see any problem with having this many parameters when all of those parameters are relevant (see: Vulkan). Named parameters often implies default values too, which means you wouldn't have to specify them all. I basically emulate this in other languages, like Rust, with an “options” struct that has default values.