The public source code for Firefox has existed for 17+ years (since ~April 1998). We can only assume it will be around for another 10+ years.
I believe you have to take the long view on the cost benefit analysis and realize that a lot of pain in the short term (e.g. switching styles entirely) will be a fraction of the cost for tolerating inconsistent styles for years more. Yes, it will be painful to transition. But for software with a history measured in decades as opposed to months, being short-sighted will only burden us with various forms of debt in the years to come. On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
