3 ms·
>Also they can lead to a poor pattern which is functions/methods that take too many parameters. >In addition, positional arguments are simply easier to read; a
by jasode 6y ago
>Also they can lead to a poor pattern which is functions/methods that take too many parameters.
>In addition, positional arguments are simply easier to read; as keyword arguments are not ordered, you’re essentially parsing the arguments, seeking the important ones etc.
Microsoft's raw Win32 API SDK is based on the C Language and even though that language doesn't have named parameters, it still did not discourage functions designed with lots of parameters that's difficult to mentally parse.
To make such code self-documenting, this is how I typically write Win32 API calls to make the code readable:
ret = CreateProcess(NULL, // _In_opt_ LPCTSTR lpApplicationName,
cmd, // _Inout_opt_ LPTSTR lpCommandLine,
NULL, // _In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes,
NULL, // _In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes,
TRUE, // _In_ BOOL bInheritHandles,
CREATE_NO_WINDOW, // _In_ DWORD dwCreationFlags,
NULL, // _In_opt_ LPVOID lpEnvironment,
NULL, // _In_opt_ LPCTSTR lpCurrentDirectory,
&si, // _In_ LPSTARTUPINFO lpStartupInfo,
&pi); // _Out_ LPPROCESS_INFORMATION lpProcessInformation
If the language had named parameters, I wonder if Microsoft would have used them so programmers wouldn't have to sprinkle extra comments like that. (Comments are also brittle because they're not real tokens that the compiler would check.) Without the comments, it looks like this:
ret = CreateProcess(NULL,
cmd,
NULL,
NULL,
TRUE,
CREATE_NO_WINDOW,
NULL,
NULL,
&si,
&pi);
All those naked NULLs and TRUE params are very hard to parse unless you've memorized the positions.
I'm not recommending that we need the verbosity of Objective-C named parameters but I don't see how mentally relying on position is less cognitive load.
- gumby 6y agoI don’t recommend a large number of parameters in any paradigm. Your case is a good example.
- jasode 6y ago>I don’t recommend a large number of parameters in any paradigm. Your case is a good example. Sure, I understand that too many parameters is to be avoided and can point to some underlying poor architecture design. However, _if_ there's irreducible complexity that calls for 5+ parameters to minimally specify behavior, what are the better syntax options than named parameters? If you say "create a struct with members and pass the struct instead", then you're just shifting the "named params" to the "struct member names". This causes the extra verbose syntax of defining one-time-use struct variables to pass as a function argument. In contrast, named parameters in the function can act as "anonymous unnamed struct" which is cleaner. Using structs as function parameters is more useful when the structs can also be re-used elsewhere in multiple places (e.g. 3d points {x, y, z}).