Path: csiph.com!2.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!feeder5.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: "Christoph M. Becker" Newsgroups: comp.lang.javascript Subject: Re: Limit number of function parameters Date: Fri, 2 Dec 2016 20:24:53 +0100 Organization: solani.org Lines: 32 Message-ID: References: <58b433c6-37a6-45de-bc70-05ec835510ff@googlegroups.com> <17n7y8md13g1b$.kznrbim03ls$.dlg@40tude.net> <2828265.aV6nBDHxoP@PointedEars.de> <4504999.NdOOCcYCMV@PointedEars.de> <1768059.oMNUckLgyt@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: solani.org 1480706660 9824 eJwFwYEBwDAEBMCVKB7j9CX2HyF3YVBMOgIeG8t0OZlTArJGPjG9F73dZbFOuC5hNX3/Az4TKBET (2 Dec 2016 19:24:20 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Fri, 2 Dec 2016 19:24:20 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cancel-Lock: sha1:Q7groCRan/abNsi0GcGRnlxtqyA= X-User-ID: eJwFwQkBACAIA8BK8mxoHAHpH8E7GIUVTtAxmLB0I2Z6q6YETWa/U+yTAfB2Rq0FtFTx6QcU6xEL In-Reply-To: X-NNTP-Posting-Host: eJwFwQkBwDAIA0BL4wk0cigU/xJ2BwuJTg+EY7HHu2jkW5NBPRfN/ppVfS7AUd+0KQ7y6rwfIyARnw== Xref: csiph.com comp.lang.javascript:31763 On 29.11.2016 at 03:15, Scott Sauyet: > Christoph M. Becker wrote: > >> | The ideal number of arguments for a function is zero (niladic). Next >> | comes one (monadic), followed closely by two (dyadic). Three arguments >> | (triadic) should be avoided where possible. More than three >> | (polyadic) requires very special justification and then shouldn't be >> | used anyway. >> >> This rule is given in an OOP context, so for functional or procedural >> style most likely one should be added (niladic functional or procedural >> functions rarely make sense). > > I agree. This sounds exactly right. There are of course uses of unary > functions in functional programming, but that's either at the boundary of > a program or as thunks of computation set aside to be processed if > they're actually needed. Neither has anything to do with API design. Hm, did you meant "nullary" instead of "unary"? For instance, there are several useful unary functions in Rambda. >> [1] Clean Code: A Handbook of Agile Software Craftsmanship > > I don't know why that classic has never bubbled its way to the top of my > to-read list. One of these days... A caveat, though: the author appears to be as opinionated as Douglas Crockford. :-) -- Christoph M. Becker