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] <javascript:>> > 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/ab4b9551-67e4-46c4-9803-403f6113c9f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
