On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann <tzimmerm...@mozilla.com> wrote:
> The discussion has a number of good points in favor of using 'a', but I > missed convincing arguments in favor of not using 'a'. Are there any? I > don't consider "I don't get what 'a' is good for" a convincing argument. > On the other hand, I'm still unconvinced by the pro-'a' arguments I've read here. Besides roc's point about refactoring, the argument against aFoo is mainly about whether the information added is worth the noise. Adding information is not always worth it, since useless information is noise. (and increases cognitive load) The extremes are "variables are always bare" (no mFoo/gFoo/sFoo/kFoo) and "extreme Hungarian notation". (where each variable name references its scope, type, and favorite color) The former is missing very valuable information (implicit member vars!), whereas the latter definitely gets in the way. The primary argument here is whether the information aFoo adds is worth the increased cognitive load. (both of holding the information and parsing the 'real name' out of the annotated variable name) I hold that aFoo does not add useful information, since outparams should be standardized to something obvious and distinct from aFoo, and I otherwise treat arguments as locals within a function. Let's divide things up for clarity: "Args should be immutable" Clearly other people here treat arguments differently, in one instance where the recommendation is that we should not to assign to them. (in which case they should really all just be const) This seems strange to me though, since I don't see why arguments should be immutable moreso than all variables should be as immutable as possible. Unilaterally requiring that arguments be const seems at odds with acknowledging that mutability useful. (And regardless, if we want immutable args, we should enforce immutable args with const, not just name them differently) -> Wrong solution for the illustrated (and not-agreed-upon) problem. "Arg warts help illustrate information flow" If we instead don't require that args must be const, then args seems little different than intermediary locals derived from args. A subsequent call or result of a function may in fact be (eventually) purely derived from args, yet not visibly pure in that it references non-arguments. If we're tracing information flow, shouldn't the a-prefix be contagious for any local derived purely from existing a-prefixed vars? This seems like a distraction to me. Can't we just read the functions instead of using an unreliable heuristic? -> Does an unreliable heuristic warrant having a-warts? I don't think so, but this is likely the most contentious aspect. "Arg warts improve backtracking for debugging" Regardless of the validity of "Arg warts help illustrate information flow", the use-case of backtracking to 'origin' of aFoo is also unconvincing, since you'd only need to go back once more than previously before moving once back 'up'. Either way sounds eminently automateable. -> No practical change, thus irrelevant. "It's hard to implement" This is irrelevant for new code, and bulk-change is feasible once we have -Wshadow. (which isn't too hard. We shouldn't have shadowing in our code anyway, so we want -Wshadow regardless of this discussion) Besides, a number of our internal projects and modules already don't have it, so it's free for them. -> Non-trivial, but not too hard to implement. So, when you say "I like aFoo because it lets me know which vars are args", is there any un-touched-on aspect of the information "this var is an argument" that is useful to know? How does every other project survive without it? A convincing argument is one that would have been a good reason to switch to aFoo in the first place. Without this, we don't have reasons, we just have momentum. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
