Jimb, I like the idea of having a convention of assigning null / undefined instead of omitting arguments. Refactoring may indeed take more time, but as you implied - it also means more discipline and higher code quality. However, you can't always educate your users. Your method works great for APIs for which you know who are the users; but with public libraries and modules, your users are most likely not used to those conventions.
Thanks for sharing, Eyal. On Tuesday, October 7, 2014 2:06:05 AM UTC+8, Jimb Esser wrote: > > At Cloud Party, we decided to avoid the ambiguity of having optional > arguments omitted, and instead took the approach used in other languages > where you just explicitly pass null or undefined for the optional > arguments. This had the readability advantage of, given a function > signature and a call, you knew exactly which parameter was for which > argument without having to know anything about which are optional and which > are expected to be which type and what the types are in the caller. It > also allows for slightly stricter code verification (e.g. generate a linter > error if any call for a known function is missing an argument). > Refactoring was slightly more work, as you had to actually touch every > line of code that called a function when you added a new optional argument > - on the other hand, when refactoring Javascript, we've found that it's > generally pretty critical to actually inspect every line of code calling > your function, so that was not much of a downside. > > We also followed a similar rule as stated earlier in the thread - after a > function took more than 3-5 arguments, for both readability and > maintainability, change it to take an options object instead (or, in a lot > of cases where it makes sense, 1 required parameter, an optional options > object, and a callback). Though, more recently, when I'm writing a new > function signature, I generally ask myself: "Might I want to add more > optional flags/arguments in the future? If so, might as well just make it > take an options argument now". > > Though, in performance critical code (if your app has any) performance > trumps all other rules, of course =). > > On Monday, October 6, 2014 7:47:48 AM UTC-7, Adrian Lynch wrote: >> >> I like the idea. Have you used it in anger yet? How did it feel in a >> bigger code base? Did it get in the way or hinder your dev? >> >> We're having the same debate on a new app we're developing and we can't >> settle on an answer. >> >> Looking forward to more perspective on this... >> >> Adrian >> >> On 5 October 2014 18:25, Eyal Arubas <[email protected]> wrote: >> >>> I'm wondering what are some common ways to approach the problem of >>> figuring out which arguments the user has passed to a function. >>> >>> It's a problem I've encountered many times when writing libraries with >>> APIs; especially for functions with optional arguments. >>> Each such function requires logic to figure out which of the arguments >>> were supplied, and assign default values to those which weren't. >>> A function with just a few arguments requires a large chunk of code just >>> for this purpose. >>> >>> An alternative approach is to use an `options` object, the fields of >>> which represent the arguments, and directly assigned by the user. >>> This, however, imo, is less suitable for public APIs. I prefer to have >>> function signatures with distinct arguments. >>> >>> It seemed to me like there should be a programmatic solution to this. >>> Each function's arguments should hold certain conditions. Arguments must be >>> of certain types, some are optionals, some have default values, etc. >>> This led me to develop a module which allows to declare the properties >>> of the function's arguments. The module resolves tnd disambiguates the >>> arguments passed by the user based on those declarations. >>> >>> https://github.com/EyalAr/Decree >>> >>> Decree works by analyzing a list of argument declarations. It then >>> figures out all the possible combinations. >>> For example, a function which receives two arguments, with the first one >>> optional, has two possible combinations - the user can call the function >>> with one argument (thus omitting the first one), or with two (thus >>> providing the first one). >>> A function with two arguments, of which non is optional, has only one >>> combination. >>> When the user calls the function, decree will match the supplied >>> arguments to a certain combination. If no combination is found, the user >>> supplied invalid arguments. If more than one combination is found, the user >>> was not specific enough, and there is ambiguity. Decree can tell where is >>> the problem. >>> >>> How do you usually approach this problem? >>> And what do you think about this solution? >>> >>> -- >>> Job board: http://jobs.nodejs.org/ >>> New group rules: >>> https://gist.github.com/othiym23/9886289#file-moderation-policy-md >>> Old group rules: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/nodejs/714e2782-1b8b-4203-bcef-36761b65d993%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/nodejs/714e2782-1b8b-4203-bcef-36761b65d993%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/be99def3-b1d9-4fdf-a200-fa8ab4e9584d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
