Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/15/2015 3:23 AM, Benjamin Smedberg wrote: 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 I used this style in a personal project, and I quickly came to regret it. Distinguishing whether a variable is a member verses being a local var by a single '_' character I found was harder, as '_' is a very small character, and is hard to see, especially when syntax highlighting is underlining the word. Whereas the difference between a leading 'a' and 'm' is very obvious, even when syntax highlighting is underlining the word. I think adopting Google style is a bad idea. cpearce. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/14/2015 8:23 AM, Benjamin Smedberg wrote: Aww, I was avoiding getting into this thread. ... 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. I have also avoided getting into this thread, as the whole premise seems to me to be pretty clueless about what makes Mozilla code difficult for newcomers. I think I'm a pretty good authority on experience of newcomers, as I spend a pretty good part of my Mozilla life tracing out Thunderbird issues in core Mozilla code that I know very little about. Earlier in the week it was the addon manager, today it is certificate handling. I find the same thing over and over again that makes Mozilla code really difficult to approach when you are not already an expert. And it has nothing to do with whether you include the a in front of method variables or not. What is missing? The most basic description of what major functions do, and how they are supposed to interact with the rest of code. If you really to be Making new contributors productive then require that! Examples: 1) Earlier this week, it was the addon code. Checkout XPIProvider.jsm No description anywhere of what this is supposed to do or how it interacts with other code. Yes there is detailed documentation of some of the function calls, but nowhere can I understand the relationship of this to AddonManager, which seems to pretty much do he same thing just from the titles. Only by hours and hours of tracing out code can I figure out their relationship (see bug 1183733 for the final result). Documentation of function calls does not really help when, as a newcomer, you don't understand the big picture. 2) Currently, looking at some sort of regression in certificate management with STARTTLS. Look at TCPSocketChild.cpp for example, no clue anywhere in that file what it is about. Or nsNSSCertificate.cpp no clue what that really does, and the code does not give any hints. So if you want to make things easier for newcomers, require that modules have some sort of overview of what they are supposed to do, and how they interact with other code. Don't waste time on code churn with style of existing code. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 9:17 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Well consistency is a major concern, so as long as the oceans are well and truly boiled... I'm certainly no fan of snake_case, but the literature does say it's more readable, and their data is better than my anecdotes. This Modest Proposal has my vote. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
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
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/15/2015 5:47 PM, Andrew Sutherland wrote: Would it be crazy for us to resort to a poll on these things? A poll will not be useful for informing this decision. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Wed, Jul 15, 2015 at 2:26 PM, Gregory Szorc g...@mozilla.com wrote: 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. There are two uses of consistency being thrown around. One is internal consistency within the project (with our style guide), the other is consistency with Google C++ style (and lack of consistency with other things, like JS). I don't believe at all that the lack of the latter is a burden or a debt that will hamper our ability to effectively evolve Gecko, and we can get the former much more cheaply. Why make it harder for ourselves? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
Would it be crazy for us to resort to a poll on these things? I propose abusing the mozillans.org skills field in profiles. For example, I have created the following sets of skills on mozillians.org by question, and which should autocomplete if you go to the edit page for your profile at https://mozillians.org/en-US/user/edit/ a prefixing of arguments: * style-args-no-a * style-args-yes-a * style-args-dont-care Switching wholesale to the google code style: * style-google-no * style-google-yes * style-google-dont-care My rationale is: * Everyone should have a mozillians.org account and if you don't and this provides the motivation... hooray! * This avoids vote stuffing, more or less * I guess someone could easily filter it down to valid committer accounts? * This requires no work on my part after this point. * The autocomplete logic should let people add other options if they're quick on their feet. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
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
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/14/2015 10:23 AM, Benjamin Smedberg wrote: Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores The biggest problem here is that WebIDL and XPIDL codegen are heavily geared towards camelCase names, as the IDL convention is camelCase. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
May I request that the major parts of this not happen until we have a blame that can see through such changes. Last I checked, gps had some ideas in that space but lacked time to implement. On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg 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
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Jul 14, 2015, at 8:23 AM, Benjamin Smedberg benja...@smedbergs.us wrote: * no more ns prefix Are people still creating new classes with an ’ns’ prefix? Surely this is something we can drop right away, at least for new code. Much of the codebase already does not use this style. We have namespaces now, after all. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 9:06 AM, David Major dma...@mozilla.com wrote: May I request that the major parts of this not happen until we have a blame that can see through such changes. Last I checked, gps had some ideas in that space but lacked time to implement. I spoke to a Mercurial maintainer about some of my ideas and the feature would be welcome upstream. However, there isn't enough time to land for Mercurial 3.5 (code freeze this week), so we'd have to wait until Mercurial 3.6 (November 1 release date) at the earliest. That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. While I'm here, if anyone has suggestions for quick fixes to https://hg.mozilla.org/'s HTML output, those are relatively easy to make. Please file bugs against Developer Services :: hg.mozilla.org if you have ideas! And, if you want to hack on improvements yourself, https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmo/contributing.html#hacking-the-theming tells you how. I reckon we could come up with enough small changes to hold us over until commit skipping in blame is implemented. On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg 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
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc g...@mozilla.com wrote: That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. This. If blame is the only victim, and a temporary one, then that's a pretty small price to pay. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Wed, Jul 15, 2015 at 3:40 AM, Joshua Cranmer pidgeo...@gmail.com wrote: The biggest problem here is that WebIDL and XPIDL codegen are heavily geared towards camelCase names, as the IDL convention is camelCase. C++ names matching WebIDL (or spec names in general) has value. We've gotten quite close to that over the last several years. Maybe renaming tools could understand and enforce the relationship with WebIDL, but is _ identifiers everywhere except where we're matching specs the optimal long-term state? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 14 July 2015 at 08:23, Benjamin Smedberg benja...@smedbergs.us wrote: 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. The C++ world is a huge mishmash of different styles. I don't think Google style is necessarily any better than our style. And, to be fair, our style is actually fairly close to Google style with a few exceptions like variable naming. The real issue is that we have vastly different code styles throughout our codebase. We use 2 spaces for indentation in some modules and 4 spaces in others. Some places defiantly use tabs and a few files have compromised on 3 space indentation (eww!). Some modules place the pointer adjacent to the type, others put it beside the name. Some modules always brace control statements, others do not. It's not our style that is the problem for new (and old!) contributors; it's the huge inconsistency. I'm making Clang-Format compatible with our style over in bug 961541. Once Clang-Format is good enough, I will rewrite the entire tree on a directory-by-directory basis. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ If we were to do this, some names would become shorter and other longer. That might break the 80 column limit in places and break alignment in others. (Also keep in mind that Google style mandates `foo_bar()` for getters and `set_foo_bar()` for setters.) This is a general problem with rewriting. In order to perform them effectively, we need to have a consistent style and tool to automatically reformat diffs to that style. I personally don't think switching to Google style naming is worth it. It would require far more changes than just sticking with either aFooBar or fooBar for no apparent benefit. Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
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
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 8: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 FWIW, I think the Google C++ style is terrible, but if it gets us to a point where we can run clang-format as part of make check and never worry about style again I am all for it. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 07/14/2015 08:11 PM, Martin Thomson wrote: On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc g...@mozilla.com wrote: That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. This. If blame is the only victim, and a temporary one, then that's a pretty small price to pay. Couple of work days per year for certain devs? Perhaps it is a small price. Also, if we just stick with the current coding style, large parts of Gecko doesn't need to be refactored to new style. About using Google coding style, there isn't any evidence it would make new contributors more productive, and it might make old contributors less productive at least for some time. But whatever we change, if any - since the current coding style is rather sane for C++ - consistency is what I care about most. It is mystery to me why we've still written new code not using the coding style we have had for ages. I guess that is where we really need tools, enforce some style. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
