On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson <mozn...@karlt.net> wrote:
> Jeff Gilbert writes: > > > It can be a burden on the hundreds of devs who have to read and > understand > > the code in order to write more code. > > Some people find the prefix helps readability, because it makes > extra information immediately available in the code being > examined, while you are indicating that this is a significant > burden on readability. > > Can you explain why the extra letter is a significant burden? > Because extra noise is being forced into variable names for minimal benefit. Every declaration is a sea of extra 'a's. Refactoring code means doing a lot of s/aFoo/foo/ and vice-versa. Reading each arg name requires first passing over 'a' before getting to anything relevant. Often this means that short function bodies can have every fifth or sixth letter being 'a'. Why does it matter that they're arguments? Arguments are just locals that are passed into functions. (outparams are a different beast already addressed elsewhere) I would like to reiterate that *we are unusual* in our present preference (not to mention requirement) for this in our style guideline. I'm not proposing a change to something bizarre. I'm proposing the removal of an extremely unusual style requirement. If the 'a' prefix is a burden then the 'm' prefix must be also, > and so we should be using this->member instead of mMember. > No, as this provides huge benefit by indicating when we are referencing a member variable, which differ greatly from local variables in scope. Arguments have the same scope as locals. There is benefit in mFoo, particularly compared to requiring this->foo, which I don't think we even have compiler or linter support for, and would clearly be superfluous in terms of extra characters. > > > The opinions of a few over-harried > > reviewers should not hold undue sway over the many many devs writing > code. > > unless people want code to be reviewed. > `aFoo` is never going to make or break our ability to do code review. Low code-review bandwidth is all but completely orthogonal to this discussion. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
