On 29/11/2023 14:37, Marco Bonardo wrote:
In this case I prefer to add the new unused argument to all the
interfaceImpl instances during the refactoring, so when DeveloperB
arrives, they will find:
=> file.js
interfaceImpl(arg1, arg2, something) {
return arg1 + arg2;
}
that makes immediately obvious `something` can now be used directly.
I admit this may be considered an edge case, and most people are
unlikely to do it (for which it's a good idea to check the interface
definition every time), but I found it handy.
In all honesty, I was mostly wondering if unused arguments come with a
performance cost.
I don't have too strong feelings overall, as while I'd appreciate a
way out (like the _ prefix), I also see how it could be easily abused.
I think there are two "styles" of function definitions - the
observer/interface functions vs the more general function.
The biggest benefits here would be for the latter type. Highlighting
arguments which may now be unused will remind developers to remove those
and cleaning up the call tree - sometimes we could be doing now
unnecessary work to pass the unused arguments, or it might signify that
the architecture needs reworking.
Unfortunately ESLint can't distinguish between what's an
observer/interface implementation and what isn't. The underscore prefix
might be a way for observers/interface functions to still keep the
argument names. We could potentially have a code convention that it only
gets used for those style functions. Though I do think that's going to
be difficult to handle on the initial roll-out as it would require a lot
of manual intervention.
Mark
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/b53d90d6-5c1e-43b0-9135-bf75ae2e3c03%40mozilla.com.
