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
