Trailing comma for function arguments and call parameters
dmitry.soshnikov at gmail.com
Mon Jul 7 15:40:43 PDT 2014
On Sun, Jul 6, 2014 at 10:36 PM, Isiah Meadows <impinball at gmail.com> wrote:
> My responses are inline.
> > From: Alex Kocharin <alex at kocharin.ru>
> > To: Oliver Hunt <oliver at apple.com>, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com>
> > Cc: es-discuss <es-discuss at mozilla.org>
> > Date: Sun, 06 Jul 2014 12:07:09 +0400
> > Subject: Re: Trailing comma for function arguments and call parameters
> > In fact, how about the same syntax for arrays and function calls? With
> trailing commas and elisions?
> > So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?
> > 06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:
> > > Unless you use leading comma style, trailing commas are very good to
> have for anything that has variable amount of items/keys/arguments.
> > >
> > > This is a classic example I use to show why JSON is a bad idea:
> > >
> > >
> > > 04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:
> > >> On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
> > >>> Hi,
> > >>>
> > >>> Will it makes sense to standardize a trailing comma for function
> arguments, and call parameters?
> 2. Function statements usually don't have such long lists of arguments
> that such a thing would truly become useful. That is rare even in C, where
> you may have as many as 6 or 7 arguments for one function.
Yes, it's true, however, my use-case was based on 80-cols rule we use in
our code-base. And with type annotations (especially type annotations with
generics, when you have types like `Map<string, IParamDefinition> $params`,
etc) it can quickly become more than 80 cols, and our style-guide is to use
each parameter on its own line, with a trailing comma for convenience of
future adding that will preserve git blame logs if one doesn't need always
append the comma on previous line, in case when adding a new parameter.
But again, I already think that for the language itself, it won't be super
useful just yet, since backward-incompatible syntax won't allow using it
anyways for a long amount of time, and not everyone has the build/transform
step, that allows adopt this for older versions. That's said, a local
extension seems the way to go for me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss