I'm not wild about this idea. Switching styles entirely would be several times more churn and work than just making our existing codebase conform to our existing style guide. Consistency with Google's style might be a nice bonus, and there might be subjective arguments for one or the other, but none of that seems worth the churn and disruption this would cause, IMO.
On Tue, Jul 14, 2015 at 11:23 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > > > On 7/8/2015 7:31 AM, Nathan Froyd wrote: > >> If somebody is willing to do the formatting, I'm willing to do the >> review. I think the thread has reached the point of people repeating ad >> nauseum what was already said earlier in the thread, so it's time for a >> decision. Benjamin? >> > > Aww, I was avoiding getting into this thread. > > I personally have no strong preference, and our existing community is > pretty deeply divided. I doubt we're going to come to consensus here, and > this is a pretty tough decision to make on its own. I do believe that > consistency trumps module/personal preference in terms of coding style. > > The argument I am most sympathetic to is that this convention is a barrier > to new contributors. Making new contributors productive, both employees and > volunteers, is a very good reason to choose one style over another. > > Given that premise, we shouldn't just change aArgument; we should adopt > the Google C++ style guide wholesale: > > * names_with_underscores > * members_with_trailing_ > * no more ns prefix > > There is good research that underscore_names are more readable, and many > of these will be more familiar to new contributors. Also we have a fair bit > of shared code with Google. > > If there is a decision to be made here, I'd like to make this RFC: > > * switch our codebase wholesale to the Google C++ style guide > > With the following implementation plan: > > * For now, code should continue to be written in the current style with > aFoo, mFoo, and camelCase. > * get our code -Wshadow clean > * Ask poiru to investigate auto-renaming of our variables including mFoo, > aFoo, and camelCase to the google-standard local variable names. > * Do not make any changes to the style guide or standard practice until > we're comfortable that we can do automatic changes. > * Make the automatic changes and change our style guide at roughly the > same time. > * Go back and deal with class names (nsFoo) as a separate/later pass. > > --BDS > > _______________________________________________ > 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
