MM
Magnus Melin
Tue, Nov 27, 2018 10:04 PM
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding out
parameters. If you're using out parameters in regular JavaScript, you're
probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
-Magnus
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding out
parameters. If you're using out parameters in regular JavaScript, you're
probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
-Magnus
GL
Geoff Lankow
Tue, Nov 27, 2018 10:12 PM
The Mozilla ESLint plugin has a rule that can help with this:
mozilla/no-aArgs. It's enabled in a few places in mozilla-central, we
could do the same.
GL
On 28/11/18 11:04, Magnus Melin wrote:
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding
out parameters. If you're using out parameters in regular JavaScript,
you're probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
-Magnus
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
The Mozilla ESLint plugin has a rule that can help with this:
mozilla/no-aArgs. It's enabled in a few places in mozilla-central, we
could do the same.
GL
On 28/11/18 11:04, Magnus Melin wrote:
> We have a bunch of code that is using aNaming for function arguments.
> I'd like to propose we officially drop this convention in JavaScript
> code. So instead function(aName, aTitle) { ... }, just function(name,
> title) { ... }
>
> In C/C++ adding "a" for argument can be useful especially regarding
> out parameters. If you're using out parameters in regular JavaScript,
> you're probably doing something wrong.
>
> In short, in JavaScript, the "a" adds no value, and is quite ugly.
>
> -Magnus
>
>
> _______________________________________________
> Maildev mailing list
> Maildev@lists.thunderbird.net
> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
>
BB
Ben Bucksch
Tue, Nov 27, 2018 10:34 PM
Magnus Melin schrieb am 27.11.18 um 23:04:
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding
out parameters. If you're using out parameters in regular JavaScript,
you're probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
Completely agreed. The aFoo feels unnatural, and it's not helpful,
because the function parameters are declared right above, easy to see.
(Let's not refactor existing code, please, though. That would introduce
too much change noise.)
Magnus Melin schrieb am 27.11.18 um 23:04:
> We have a bunch of code that is using aNaming for function arguments.
> I'd like to propose we officially drop this convention in JavaScript
> code. So instead function(aName, aTitle) { ... }, just function(name,
> title) { ... }
>
> In C/C++ adding "a" for argument can be useful especially regarding
> out parameters. If you're using out parameters in regular JavaScript,
> you're probably doing something wrong.
>
> In short, in JavaScript, the "a" adds no value, and is quite ugly.
Completely agreed. The aFoo feels unnatural, and it's not helpful,
because the function parameters are declared right above, easy to see.
(Let's not refactor existing code, please, though. That would introduce
too much change noise.)
PK
Philipp Kewisch
Tue, Nov 27, 2018 10:58 PM
On 11/27/18 11:34 PM, Ben Bucksch wrote:
Magnus Melin schrieb am 27.11.18 um 23:04:
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding
out parameters. If you're using out parameters in regular JavaScript,
you're probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
Completely agreed. The aFoo feels unnatural, and it's not helpful,
because the function parameters are declared right above, easy to see.
(Let's not refactor existing code, please, though. That would
introduce too much change noise.)
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member. I know that a full hungarian notation would also go
into types etc though. mMember is not that important since JavaScript
always requires use of |this.mMember| instead of just mMember, but aArg
is not that unambiguous.
The benefit of aArgs becomes obvious in larger functions. At the
beginning you still read it as a function argument, but later on you
might not see it and reassign it. This mutates the |arguments| object,
and is probably not the best style either.
I'm fine with enabling mozilla/no-aArgs if we also enable
https://eslint.org/docs/rules/no-param-reassign .
I would aim to refactor existing code though. It might introduce some
noise, but from experience in calendar if we don't do it at once, it
will still be around in some places in 10 years time. If we must, we can
use [skip-blame] in hopes mercurial will support it. Given that changing
argument names has a risk for regressions where there was already an
existing variable with the same name, we should probably not skip blame
though. https://eslint.org/docs/rules/no-shadow may help here as well.
Philipp
On 11/27/18 11:34 PM, Ben Bucksch wrote:
> Magnus Melin schrieb am 27.11.18 um 23:04:
>> We have a bunch of code that is using aNaming for function arguments.
>> I'd like to propose we officially drop this convention in JavaScript
>> code. So instead function(aName, aTitle) { ... }, just function(name,
>> title) { ... }
>>
>> In C/C++ adding "a" for argument can be useful especially regarding
>> out parameters. If you're using out parameters in regular JavaScript,
>> you're probably doing something wrong.
>>
>> In short, in JavaScript, the "a" adds no value, and is quite ugly.
>
>
> Completely agreed. The aFoo feels unnatural, and it's not helpful,
> because the function parameters are declared right above, easy to see.
>
>
> (Let's not refactor existing code, please, though. That would
> introduce too much change noise.)
>
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member. I know that a full hungarian notation would also go
into types etc though. mMember is not that important since JavaScript
always requires use of |this.mMember| instead of just mMember, but aArg
is not that unambiguous.
The benefit of aArgs becomes obvious in larger functions. At the
beginning you still read it as a function argument, but later on you
might not see it and reassign it. This mutates the |arguments| object,
and is probably not the best style either.
I'm fine with enabling mozilla/no-aArgs if we also enable
https://eslint.org/docs/rules/no-param-reassign .
I would aim to refactor existing code though. It might introduce some
noise, but from experience in calendar if we don't do it at once, it
will still be around in some places in 10 years time. If we must, we can
use [skip-blame] in hopes mercurial will support it. Given that changing
argument names has a risk for regressions where there was already an
existing variable with the same name, we should probably not skip blame
though. https://eslint.org/docs/rules/no-shadow may help here as well.
Philipp
BB
Ben Bucksch
Wed, Nov 28, 2018 1:05 AM
Philipp Kewisch schrieb am 27.11.18 um 23:58:
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member.
The difference between member vars and function parameters is that
a) function params are declared right above the code that you read
(similar to local vars)
b) function params have local scope, just like local vars, whereas
member vars have effect outside your function
Philipp Kewisch schrieb am 27.11.18 um 23:58:
> I actually like aArgs. It is afaik not for out parameters, but to
> differentiate kinds of variables. Similar to how you might use mMember
> for a class member.
The difference between member vars and function parameters is that
a) function params are declared right above the code that you read
(similar to local vars)
b) function params have local scope, just like local vars, whereas
member vars have effect outside your function
PK
Philipp Kewisch
Wed, Nov 28, 2018 8:28 AM
On 11/28/18 2:05 AM, Ben Bucksch wrote:
Philipp Kewisch schrieb am 27.11.18 um 23:58:
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member.
The difference between member vars and function parameters is that
a) function params are declared right above the code that you read
(similar to local vars)
This may change if it is a longer function. Sometimes variables have
tempting names, that invite you to assign to them. If you don't have the
function head in mind because you are just doing a small patch, you may
forget.
b) function params have local scope, just like local vars, whereas
member vars have effect outside your function
This is true, but the direction is not the one I intended. I know member
vars are different, and especially in JavaScript the comparison may be
moot because member vars are always prefixed with |this|. What I am
saying is that the "a" prefix does not denote an out parameter, but the
fact the variable is an argument, as opposed to a locally scoped
variable in the function block.
Anyway, with no-shadow, no-param-reassign and mozilla/no-aArgs all my
points are covered.
Philipp
On 11/28/18 2:05 AM, Ben Bucksch wrote:
> Philipp Kewisch schrieb am 27.11.18 um 23:58:
>> I actually like aArgs. It is afaik not for out parameters, but to
>> differentiate kinds of variables. Similar to how you might use mMember
>> for a class member.
>
>
> The difference between member vars and function parameters is that
>
> a) function params are declared right above the code that you read
> (similar to local vars)
This may change if it is a longer function. Sometimes variables have
tempting names, that invite you to assign to them. If you don't have the
function head in mind because you are just doing a small patch, you may
forget.
>
> b) function params have local scope, just like local vars, whereas
> member vars have effect outside your function
>
This is true, but the direction is not the one I intended. I know member
vars are different, and especially in JavaScript the comparison may be
moot because member vars are always prefixed with |this|. What I am
saying is that the "a" prefix does not denote an out parameter, but the
fact the variable is an argument, as opposed to a locally scoped
variable in the function block.
Anyway, with no-shadow, no-param-reassign and mozilla/no-aArgs all my
points are covered.
Philipp
MM
Magnus Melin
Wed, Nov 28, 2018 9:17 AM
On 28-11-2018 00:58, Philipp Kewisch wrote:
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member.
Sure, I just meant that for out parameters it can sometimes be more
clear with an aName, since local variables you obviously can't send back
out.
The mMember notation we should also drop, but that's not used much in
our js files currently either.
Sounds good to me.
-Magnus
On 28-11-2018 00:58, Philipp Kewisch wrote:
>
>> I actually like aArgs. It is afaik not for out parameters, but to
>> differentiate kinds of variables. Similar to how you might use mMember
>> for a class member.
Sure, I just meant that for out parameters it can sometimes be more
clear with an aName, since local variables you obviously can't send back
out.
The mMember notation we should also drop, but that's not used much in
our js files currently either.
>> I'm fine with enabling mozilla/no-aArgs if we also enable
>> https://eslint.org/docs/rules/no-param-reassign .
Sounds good to me.
-Magnus
PC
Patrick Cloke
Wed, Nov 28, 2018 2:17 PM
On 11/27/18 5:58 PM, Philipp Kewisch wrote:
On 11/27/18 11:34 PM, Ben Bucksch wrote:
Magnus Melin schrieb am 27.11.18 um 23:04:
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding
out parameters. If you're using out parameters in regular JavaScript,
you're probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
Completely agreed. The aFoo feels unnatural, and it's not helpful,
because the function parameters are declared right above, easy to see.
(Let's not refactor existing code, please, though. That would
introduce too much change noise.)
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member. I know that a full hungarian notation would also go
into types etc though. mMember is not that important since JavaScript
always requires use of |this.mMember| instead of just mMember, but aArg
is not that unambiguous.
The benefit of aArgs becomes obvious in larger functions. At the
beginning you still read it as a function argument, but later on you
might not see it and reassign it. This mutates the |arguments| object,
and is probably not the best style either.
I'm fine with enabling mozilla/no-aArgs if we also enable
https://eslint.org/docs/rules/no-param-reassign .
I would aim to refactor existing code though. It might introduce some
noise, but from experience in calendar if we don't do it at once, it
will still be around in some places in 10 years time. If we must, we can
use [skip-blame] in hopes mercurial will support it. Given that changing
argument names has a risk for regressions where there was already an
existing variable with the same name, we should probably not skip blame
though. https://eslint.org/docs/rules/no-shadow may help here as well.
Philipp
I'm unsure if I have a strong option on aFoo, but it seems like we might
want to enable these no-param-reassign and no-shadow anyway. Those would
be beneficial regardless if we change the names of arguments.
--Patrick
On 11/27/18 5:58 PM, Philipp Kewisch wrote:
> On 11/27/18 11:34 PM, Ben Bucksch wrote:
>> Magnus Melin schrieb am 27.11.18 um 23:04:
>>> We have a bunch of code that is using aNaming for function arguments.
>>> I'd like to propose we officially drop this convention in JavaScript
>>> code. So instead function(aName, aTitle) { ... }, just function(name,
>>> title) { ... }
>>>
>>> In C/C++ adding "a" for argument can be useful especially regarding
>>> out parameters. If you're using out parameters in regular JavaScript,
>>> you're probably doing something wrong.
>>>
>>> In short, in JavaScript, the "a" adds no value, and is quite ugly.
>>
>> Completely agreed. The aFoo feels unnatural, and it's not helpful,
>> because the function parameters are declared right above, easy to see.
>>
>>
>> (Let's not refactor existing code, please, though. That would
>> introduce too much change noise.)
>>
> I actually like aArgs. It is afaik not for out parameters, but to
> differentiate kinds of variables. Similar to how you might use mMember
> for a class member. I know that a full hungarian notation would also go
> into types etc though. mMember is not that important since JavaScript
> always requires use of |this.mMember| instead of just mMember, but aArg
> is not that unambiguous.
>
> The benefit of aArgs becomes obvious in larger functions. At the
> beginning you still read it as a function argument, but later on you
> might not see it and reassign it. This mutates the |arguments| object,
> and is probably not the best style either.
>
> I'm fine with enabling mozilla/no-aArgs if we also enable
> https://eslint.org/docs/rules/no-param-reassign .
>
> I would aim to refactor existing code though. It might introduce some
> noise, but from experience in calendar if we don't do it at once, it
> will still be around in some places in 10 years time. If we must, we can
> use [skip-blame] in hopes mercurial will support it. Given that changing
> argument names has a risk for regressions where there was already an
> existing variable with the same name, we should probably not skip blame
> though. https://eslint.org/docs/rules/no-shadow may help here as well.
>
> Philipp
I'm unsure if I have a strong option on aFoo, but it seems like we might
want to enable these no-param-reassign and no-shadow anyway. Those would
be beneficial regardless if we change the names of arguments.
--Patrick
I
ISHIKAWA,chiaki
Wed, Nov 28, 2018 4:00 PM
On 2018/11/28 7:58, Philipp Kewisch wrote:
On 11/27/18 11:34 PM, Ben Bucksch wrote:
Magnus Melin schrieb am 27.11.18 um 23:04:
We have a bunch of code that is using aNaming for function arguments.
I'd like to propose we officially drop this convention in JavaScript
code. So instead function(aName, aTitle) { ... }, just function(name,
title) { ... }
In C/C++ adding "a" for argument can be useful especially regarding
out parameters. If you're using out parameters in regular JavaScript,
you're probably doing something wrong.
In short, in JavaScript, the "a" adds no value, and is quite ugly.
Completely agreed. The aFoo feels unnatural, and it's not helpful,
because the function parameters are declared right above, easy to see.
(Let's not refactor existing code, please, though. That would
introduce too much change noise.)
I actually like aArgs. It is afaik not for out parameters, but to
differentiate kinds of variables. Similar to how you might use mMember
for a class member. I know that a full hungarian notation would also go
into types etc though. mMember is not that important since JavaScript
always requires use of |this.mMember| instead of just mMember, but aArg
is not that unambiguous.
The benefit of aArgs becomes obvious in larger functions. At the
beginning you still read it as a function argument, but later on you
might not see it and reassign it. This mutates the |arguments| object,
and is probably not the best style either.
I'm fine with enabling mozilla/no-aArgs if we also enable
https://eslint.org/docs/rules/no-param-reassign .
I would aim to refactor existing code though. It might introduce some
noise, but from experience in calendar if we don't do it at once, it
will still be around in some places in 10 years time. If we must, we can
use [skip-blame] in hopes mercurial will support it.
TB project ought to set up a flag day and announce it when such a change
is introduced.
It should probably be more like a few series of flag days: some changes
are done to a set of files under a single directory. So the flag day can
be set for affected directory.
The notion of "flag day" first came up in Multics before my time.
I recall linux SCSI subsystem had a flag day so that all the code in
SCSI subsystem went through mechanical reformatting to make them conform
to mechanical format rules: before, there were cases of spaghetti code
which were very hard to read.
(This was done circa 2000.)
Of course, as mentioned below, we can use every mechanical help to
reduce regression.
Given that changing
argument names has a risk for regressions where there was already an
existing variable with the same name, we should probably not skip blame
though. https://eslint.org/docs/rules/no-shadow may help here as well.
Philipp
I think we should hope for some VCS front-end work to reduce noise by
omitting these changes done on a flag day if possible.
My two cents worth.
Chiaki Ishikawa
On 2018/11/28 7:58, Philipp Kewisch wrote:
> On 11/27/18 11:34 PM, Ben Bucksch wrote:
>> Magnus Melin schrieb am 27.11.18 um 23:04:
>>> We have a bunch of code that is using aNaming for function arguments.
>>> I'd like to propose we officially drop this convention in JavaScript
>>> code. So instead function(aName, aTitle) { ... }, just function(name,
>>> title) { ... }
>>>
>>> In C/C++ adding "a" for argument can be useful especially regarding
>>> out parameters. If you're using out parameters in regular JavaScript,
>>> you're probably doing something wrong.
>>>
>>> In short, in JavaScript, the "a" adds no value, and is quite ugly.
>>
>> Completely agreed. The aFoo feels unnatural, and it's not helpful,
>> because the function parameters are declared right above, easy to see.
>>
>>
>> (Let's not refactor existing code, please, though. That would
>> introduce too much change noise.)
>>
> I actually like aArgs. It is afaik not for out parameters, but to
> differentiate kinds of variables. Similar to how you might use mMember
> for a class member. I know that a full hungarian notation would also go
> into types etc though. mMember is not that important since JavaScript
> always requires use of |this.mMember| instead of just mMember, but aArg
> is not that unambiguous.
>
> The benefit of aArgs becomes obvious in larger functions. At the
> beginning you still read it as a function argument, but later on you
> might not see it and reassign it. This mutates the |arguments| object,
> and is probably not the best style either.
>
> I'm fine with enabling mozilla/no-aArgs if we also enable
> https://eslint.org/docs/rules/no-param-reassign .
>
> I would aim to refactor existing code though. It might introduce some
> noise, but from experience in calendar if we don't do it at once, it
> will still be around in some places in 10 years time. If we must, we can
> use [skip-blame] in hopes mercurial will support it.
>
TB project ought to set up a flag day and announce it when such a change
is introduced.
It should probably be more like a few series of flag days: some changes
are done to a set of files under a single directory. So the flag day can
be set for affected directory.
The notion of "flag day" first came up in Multics before my time.
I recall linux SCSI subsystem had a flag day so that all the code in
SCSI subsystem went through mechanical reformatting to make them conform
to mechanical format rules: before, there were cases of spaghetti code
which were very hard to read.
(This was done circa 2000.)
Of course, as mentioned below, we can use every mechanical help to
reduce regression.
> Given that changing
> argument names has a risk for regressions where there was already an
> existing variable with the same name, we should probably not skip blame
> though. https://eslint.org/docs/rules/no-shadow may help here as well.
>
> Philipp
>
I think we should hope for some VCS front-end work to reduce noise by
omitting these changes done on a flag day if possible.
My two cents worth.
Chiaki Ishikawa
