On 2019-09-05 23:14, Emilio Cobos Álvarez wrote:
Yeah, let's not add a new prefix please.
I don't like aFoo either, though it's everywhere so consistency is
better than nothing :/.
That being said, it shouldn't be hard to write some clang plugin or
such that automatically renames function arguments to stop using aFoo,
should we want to do that... Just throwing it in the air, and
volunteering if we agreed to do that ;)
I personally find it useful (the 'a' prefix) same as the 'm' prefix.
When I trace back where from an argument is coming, when it bubbles down
few functions, it's good to see when it changes from 'aArg' to 'arg' ->
ah, here we set the value!
-hb-
-- Emilio
On 9/5/19 10:55 PM, Jeff Gilbert wrote:
I remain against aFoo style. I still think it's
low-signal-high-noise, and
doesn't provide value that modern syntax highlighting doesn't provide
for
those who find it useful.
I'm absolutely opposed to adding a new prefix. That would be moving even
further down the path of our proprietary code-smell.
On Thu, Sep 5, 2019 at 6:15 AM Simon Giesecke <sgiese...@mozilla.com>
wrote:
Hi,
we encountered the question of how to name parameters in lambda
expressions.
For regular functions, the coding style implies that parameter naming
should use camelCase with an "a" prefix, and this is also widely done
this way. The coding style does not say anything specifically
concerning lambda expressions at the moment. Actual uses differ at
least between using the a prefix and using no prefix.
Since in most cases, lambda expressions occur within a regular
function, using the a prefix leads to some ambiguity when reading the
code, as one cannot immediately tell whether an a-prefixed identifier
is a parameter to the lambda expression or to the enclosing function
(which may be captured).
For example, one might have:
bool MyFunction(const nsTArray<Foo>& aFoos, const nsCString &aId) {
if (std::any_of(aFoos.begin(), aFoos.end(), [aId](const Foo& aFoo) {
return aFoo.Id() == aId;
}) {
// do something more...
return true;
}
return false;
}
This is a simple case, where this might not be particularly
problematic, but I find it quite confusing to use aFoo as a lambda
parameter name. Obviously, when not using a prefix, similar
ambiguities with local variable names in the enclosing function may
arise. For some subjective reason, I find this less confusing, but
this may be different for others. Using a different prefix, e.g. l,
leading to calling the lambda parameter lFoo, would resolve this
ambiguity, but one might feel there are too many different prefixes.
While I have some personal preference against the a prefix here, I
think any of these options were acceptable. Maybe this has already
been discussed and concluded before, but not put into the coding style
document?
Simon
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
