Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 11:49 AM, Mike Conley mcon...@mozilla.com wrote: Aren't there tools for our (admittedly varied) editors / IDEs to make the readability that people are getting from aFoo readily available, but that don't also require us to pack it into the actual name of the variable? I find it useful for reading code in an editor, but I also find it useful for reviewing patches when I don't have full context of the function. Perhaps that will change with ReviewBoard and its ability to easily provide context...or if ReviewBoard learned how to provide this variable is a (local|global|argument), set on line X tooltips or something. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Karl Tomlinson mailto:mozn...@karlt.net July 7, 2015 at 12:55 AM I find the 'a' prefix useful to tell me that this variable has the value that was provided to the function. (I'm assuming that the prefix is used with this convention.) There's no additional safety enforced, but I find the single letter helps readability. For example, if I want to know where the value of a variable comes from, and it starts with 'a', then I know immediately that I can skip looking at that particular function in the call chain/graph and I need to look at the calling function(s). That advantage does not exist in a declaration that is not a definition; this is only helpful in the definition. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform FWIW, as a tech writer that has to take all this stuff and make sense of it in documentation, I dislike aFoo but I'm fine with mFood and such to differentiate methods from properties from constants, etc. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/15 11:49 AM, Mike Conley wrote: I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs And debuggers. And dxr and blame views? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs to make the readability that people are getting from aFoo readily available, but that don't also require us to pack it into the actual name of the variable? On 07/07/2015 11:44 AM, Boris Zbarsky wrote: On 7/7/15 11:36 AM, Jeff Muizelaar wrote: FWIW, I did a quick poll of the people in our Gfx daily. Here are the results: To add some more split opinions to the situation, I rather like the aArgument form precisely because it makes it easier to trace dataflow. Though the fact that some functions assign to the aArgument does make it harder. On the other hand, the last time we had this conversation (it just keeps happening, doesn't it?) roc pointed out that the aFoo convention makes it harder to refactor things into helper functions (or out of them): suddenly something that was a function local becomes an argument to the helper, and you have to rename it throughout the helper function body. I seem to recall that he also posited that this makes us less willing to refactor things into smaller functions than we should be. I don't have a good counterargument for this; I think he's right about this drawback of the aFoo convention. -Boris ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta kgu...@mozilla.com wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in your coding environment)? All the time. -Ekr I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. Also FWIW in the current world I do find the prefix useful when debugging in gdb, because I know I can keep going up a frame as long as I'm tracing a variable with the prefix, whereas otherwise I would have to step backwards through each frame to see where the variable is coming from. I'll probably find some way to adapt if we remove the prefix though. kats On Tue, Jul 7, 2015 at 7:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- On 7/7/2015 5:12, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/15 11:36 AM, Jeff Muizelaar wrote: FWIW, I did a quick poll of the people in our Gfx daily. Here are the results: To add some more split opinions to the situation, I rather like the aArgument form precisely because it makes it easier to trace dataflow. Though the fact that some functions assign to the aArgument does make it harder. On the other hand, the last time we had this conversation (it just keeps happening, doesn't it?) roc pointed out that the aFoo convention makes it harder to refactor things into helper functions (or out of them): suddenly something that was a function local becomes an argument to the helper, and you have to rename it throughout the helper function body. I seem to recall that he also posited that this makes us less willing to refactor things into smaller functions than we should be. I don't have a good counterargument for this; I think he's right about this drawback of the aFoo convention. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I agree with Karl that, the 'a' prefix sometimes helps me in that way when I read code. Also it is sometimes convenient to have a local variable use the parameter name without the prefix, like: SomeType foo = CastOrUnwrap(aFoo); I don't have strong opinion on this, though. If the majority of the industry disagrees with this style, probably we should change. - Xidorn On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 4:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- Please expand on this. I review a lot of code, and can't remember the last time knowing a var was an arg was useful. The only exception is 'out-vars', which I believe should be handled as a different case. (WebGL code generally uses the out_ prefix) `aFoo` does not discriminate, so it's impossible to tell if assignment to `aFoo` is local or not without more context. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. -Olli On 07/07/2015 06:12 AM, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/2015 19:38, Boris Zbarsky wrote: On 7/7/15 11:49 AM, Mike Conley wrote: I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs And debuggers. And dxr and blame views? IMO it's not good to be that dependent on viewers/editors when you can get the info just from the var name. -hb- -Boris ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
If we do unify Gecko/SpiderMonkey styles (something it seems like we're moving towards and I think would be great), it would be a real shame to switch 'cx' (a parameter to basically every function in SpiderMonkey) to 'aCx'; that would really make some eyes bleed. One compromise could be to drop the 'a'-prefix requirement for 1- or 2-length parameter names, since this is when it really looks silly. (But I'd prefer to drop the 'a' prefix altogether.) On Tue, Jul 7, 2015 at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/7/15 11:49 AM, Mike Conley wrote: I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs And debuggers. And dxr and blame views? -Boris ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta kgu...@mozilla.com wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in your coding environment)? I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well? Long functions (which have poor readability anyway) generally have so much going on that the trivia of which vars are args does not seem very useful.. I do not see how `aFoo` helps here, so please expand on this. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New Telemetry dashboards!
We noticed a lot of Mozillians struggle to use the Telemetry dashboards effectively. It can be difficult to interpret the graphs numbers, hard to find or filter the data, and there is a risk of making the wrong conclusions. The dashboards needed an overhaul. Anthony Zhang, our summer intern, has been working on redesigning the dashboards over the last month. Blake Winton from the UX team gave us pointers on the UI, and people around the Toronto office helped us to test the prototypes. I think we have a much more user-friendly design as result. The new dashboards are here: https://telemetry.mozilla.org I invite you to try out the new Histogram and Evolution dashes and leave your feedback here: https://etherpad.mozilla.org/new-telemetry-dash-feedback Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. FAQs: - If you'd prefer to continue to use the old dashboard, we kept it here: https://telemetry.mozilla.org/advanced/ - Anthony will soon be adding support for keyed histograms (bug 1151756) and count histograms (1172113) to the dashboards - Anthony is adding a table view to the Histogram dashboards - We also have prototype dashes connected to the new, unified Telemetry backend (histogram http://anthony-zhang.me/telemetry-dashboard/dist.html and evolution http://anthony-zhang.me/telemetry-dashboard/evo.html) - Dashboard source: https://github.com/mozilla/telemetry-dashboard/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
Can we fix the UX? Presumably we will never have zero shutdown hangs and there may be different/better ways to prompt the user about it. On Mon, Jul 6, 2015 at 10:48 PM, Vladan D vdje...@mozilla.com wrote: KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's lousy UX. The crash-reporter dialog pops up a minute after the user closed Firefox On Monday, July 6, 2015 at 4:37:41 PM UTC-4, RyanVM wrote: On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ 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: New Telemetry dashboards!
On 7/7/15 2:26 PM, Vladan Djeric wrote: Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. When I first load https://telemetry.mozilla.org/ it says, in the console: ReferenceError: CustomSelector is not defined dashboard.js:674:5 and the spinner just keeps spinning. Clicking the Add another series button doesn't seem to work. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Telemetry dashboards!
It looks like there is some kind of bug with propagating the changes to the (static) dashboard files in S3, somehow causing the old dash to be shown at telemetry.mozilla.org for some users. Others are reporting dashes that don't load. Apologies for the (very embarassing) technical difficulties. I'll post here again once these deployment issues are sorted out. On Tue, Jul 7, 2015 at 2:26 PM, Vladan Djeric vdje...@mozilla.com wrote: We noticed a lot of Mozillians struggle to use the Telemetry dashboards effectively. It can be difficult to interpret the graphs numbers, hard to find or filter the data, and there is a risk of making the wrong conclusions. The dashboards needed an overhaul. Anthony Zhang, our summer intern, has been working on redesigning the dashboards over the last month. Blake Winton from the UX team gave us pointers on the UI, and people around the Toronto office helped us to test the prototypes. I think we have a much more user-friendly design as result. The new dashboards are here: https://telemetry.mozilla.org I invite you to try out the new Histogram and Evolution dashes and leave your feedback here: https://etherpad.mozilla.org/new-telemetry-dash-feedback Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. FAQs: - If you'd prefer to continue to use the old dashboard, we kept it here: https://telemetry.mozilla.org/advanced/ - Anthony will soon be adding support for keyed histograms (bug 1151756) and count histograms (1172113) to the dashboards - Anthony is adding a table view to the Histogram dashboards - We also have prototype dashes connected to the new, unified Telemetry backend (histogram http://anthony-zhang.me/telemetry-dashboard/dist.html and evolution http://anthony-zhang.me/telemetry-dashboard/evo.html) - Dashboard source: https://github.com/mozilla/telemetry-dashboard/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/2015 21:27, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 4:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- Please expand on this. Not sure how. I simply find it useful since I was once forced to obey it strictly in a dom code. It simply has its meaning. It helps to orient. I don't know what more you want from me to hear. I review a lot of code, and can't remember the last time knowing a var was an arg was useful. The only exception is 'out-vars', which I believe should be handled as a different case. (WebGL code generally uses the out_ prefix) `aFoo` does not discriminate, so it's impossible to tell if assignment to `aFoo` is local or not without more context. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 1:03 PM, smaug opet...@mozilla.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. When and why is this useful to know? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 07/07/2015 10:55 PM, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 12:36 PM, Honza Bambas hbam...@mozilla.com wrote: On 7/7/2015 21:27, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 4:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- Please expand on this. Not sure how. I simply find it useful since I was once forced to obey it strictly in a dom code. It simply has its meaning. It helps to orient. I don't know what more you want from me to hear. I would like to have reasons why 'we' feel it's necessary or helpful when the rest of the industry (and nearly half our own company) appears to do fine without it. If we deviate from widespread standards, we should have reasons to back our deviation. More acutely, my module does not currently use `aFoo`, and our (few) contributors do not use use or like it. `aFoo` gets in the way for us. Recently, there has been pressure to unify the module's style with the rest of Gecko. The main complaint I have with Gecko style is `aFoo` being required. Vague desires for `aFoo` are not compelling. There needs to be solid reasons. If there are no compelling reasons, the requirement should be removed. We have deprecated style before, and we can do it again. readability / easier to follow the dataflow are rather compelling reasons. I selfishly try to get the time I spend on reviewing a patch shorter, and aFoo helps with that. Though even more important is consistent coding style everywhere (per programming language). -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Mon, Jul 6, 2015 at 8:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I propose we strike the `aFoo` recommendation from the Mozilla style guide. Just so the proposal doesn't get lost in the bike shed, Jeff is only proposing a change to the style guide, not a tree-wide find/replace project. I take that to mean that When in Rome still applies to existing C++ code. Do we have consensus on that part? --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Mon, Jul 6, 2015 at 8:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. I don't always respond in threads like this, but when I do, it's to say a big +1 to no more aFoo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: On 07/07/2015 11:45 PM, Milan Sreckovic wrote: Removing the style guide for “prefix function arguments with a” will not preclude people from naming a variable aFoo. At least the current style guide precludes people from naming non-function arguments that way, albeit indirectly. I’m trying to understand the possible outcomes of this particular conversation: a) Nothing happens. We leave a prefix in the style guide, some code ignores it, some follows it. until the tools (and poiru) are run and make the code follow Mozilla coding style. Assuming you're talking about clang-format, that doesn't take care about anything else than whitespaces. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 1:20 PM, smaug opet...@mozilla.com wrote: readability / easier to follow the dataflow are rather compelling reasons. It hurts readability for me and many others. I don't see how it revolutionizes following dataflow, since we have locals that are pure functions of args, but yet are not marked aFoo. Outvars are a different beast, and in at least WebGL code, are marked as such. (`out_` prefix) `aFoo` is not a good solution for outvars. If outvars are the main reason for `aFoo`, we should stop using `aFoo` for all arguments, and only mark outvars. I selfishly try to get the time I spend on reviewing a patch shorter, and aFoo helps with that. It hinders my patch reviewing. I've been speaking to those around me, and they do not see any value in differentiating args from locals. (args are just locals, anyway) Though even more important is consistent coding style everywhere (per programming language). Why don't we come into consistency with the industry at large, and also the number of internal Mozilla projects which choose not to use `aFoo`. I have found no other style guide that recommends `aFoo`. Why are we different? Why do we accept reduced readability for all external contributors? Why do so many other Mozilla projects not use this alleged readability aid? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 07/07/2015 11:45 PM, Milan Sreckovic wrote: Removing the style guide for “prefix function arguments with a” will not preclude people from naming a variable aFoo. At least the current style guide precludes people from naming non-function arguments that way, albeit indirectly. I’m trying to understand the possible outcomes of this particular conversation: a) Nothing happens. We leave a prefix in the style guide, some code ignores it, some follows it. until the tools (and poiru) are run and make the code follow Mozilla coding style. b) We change the style guide to remove the a prefix 1) We wholesale modify the code to remove the prefix, catching scenarios where we have a clash 2) We don’t do a wholesale modification i) We get rid of a’s as we modify the code anyway ii) We get rid of a’s one file at a time as we see fit iii) We get rid of a’s one function at a time c) We change the style guide to prohibit the a prefix 1) We wholesale modify the code to remove the prefix, catching scenarios where we have a clash 2) We don’t do a wholesale modification i) We get rid of a’s as we modify the code anyway ii) We get rid of a’s one file at a time as we see fit iii) We get rid of a’s one function at a time I can’t imagine the mess of any option that includes “1” and wholesale code modification, and if you remove those, the rest of the sort of start looking more or less the same. I find a’s useful, but I’ve spent enough time in different codebases that I don’t think those types of things are ever worth the level of energy we expend on them. As long as we’re not adding _ in the variable names. That’s just wrong. ;) — - Milan On Jul 7, 2015, at 16:33 , Jeff Gilbert jgilb...@mozilla.com wrote: ... I have found no other style guide that recommends `aFoo`. Why are we different? Why do we accept reduced readability for all external contributors? Why do so many other Mozilla projects not use this alleged readability aid? ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 3:33 PM, Jeff Gilbert jgilb...@mozilla.com wrote: On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta kgu...@mozilla.com wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in your coding environment)? I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well? Long functions (which have poor readability anyway) generally have so much going on that the trivia of which vars are args does not seem very useful.. I do not see how `aFoo` helps here, so please expand on this. The only concrete use case I have is what I said in my original post (the paragraph you didn't quote): when debugging in gdb it's useful to know if a variable came from the current stack frame or from a stack frame further up. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Outvars are good candidates for having markings in the variable name. `aFoo` for all arguments is a poor solution for this, though. On Tue, Jul 7, 2015 at 1:22 PM, smaug opet...@mozilla.com wrote: On 07/07/2015 11:18 PM, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 1:03 PM, smaug opet...@mozilla.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. When and why is this useful to know? Most common case in Gecko is to know that one is assigning value to outparam. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Removing the style guide for “prefix function arguments with a” will not preclude people from naming a variable aFoo. At least the current style guide precludes people from naming non-function arguments that way, albeit indirectly. I’m trying to understand the possible outcomes of this particular conversation: a) Nothing happens. We leave a prefix in the style guide, some code ignores it, some follows it. b) We change the style guide to remove the a prefix 1) We wholesale modify the code to remove the prefix, catching scenarios where we have a clash 2) We don’t do a wholesale modification i) We get rid of a’s as we modify the code anyway ii) We get rid of a’s one file at a time as we see fit iii) We get rid of a’s one function at a time c) We change the style guide to prohibit the a prefix 1) We wholesale modify the code to remove the prefix, catching scenarios where we have a clash 2) We don’t do a wholesale modification i) We get rid of a’s as we modify the code anyway ii) We get rid of a’s one file at a time as we see fit iii) We get rid of a’s one function at a time I can’t imagine the mess of any option that includes “1” and wholesale code modification, and if you remove those, the rest of the sort of start looking more or less the same. I find a’s useful, but I’ve spent enough time in different codebases that I don’t think those types of things are ever worth the level of energy we expend on them. As long as we’re not adding _ in the variable names. That’s just wrong. ;) — - Milan On Jul 7, 2015, at 16:33 , Jeff Gilbert jgilb...@mozilla.com wrote: ... I have found no other style guide that recommends `aFoo`. Why are we different? Why do we accept reduced readability for all external contributors? Why do so many other Mozilla projects not use this alleged readability aid? ___ 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: GTK3 linux builds
One more group of defectors within Mozilla. From the DevTools coding standards[0]: - aArguments aAre the aDevil (don't use them please) Although, there are still some files in tree with the legacy style. [0] https://wiki.mozilla.org/DevTools/CodingStandards#Code_style On Tue, Jul 7, 2015 at 8:00 AM, chad.mil...@canonical.com wrote: On Tuesday, June 16, 2015 at 5:12:17 PM UTC-4, Mike Hommey wrote: On Tue, Jun 16, 2015 at 04:16:13PM -0400, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. If anyone has any reasons for us not to make this change it would be good to know now. FWIW, I believe Fedora is already shipping GTK3 builds of Firefox. I depends on what our target GTK3 version would be. If, as recently suggested, we go with 3.14 as the minimum supported, that's fairly new (9 months old), and switching our builds to GTK3 would make us drop support for a lot of people that use older systems. I thought we'd be shipping both GTK2 and GTK3 builds for a while. Mike In Ubuntu, we don't have a strong preference for Gtk2 versus Gtk3, but it is important for us to support Gtk-3.4. We are obligated to keep Ubuntu 12.04 updated for a while still. So, if you don't change the current library versions on Mozilla's test machines, I'm happy. Please keep dependencies to Gtk-3.4 at latest. - chad ___ 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: mozilla::TemporaryRef is gone; please use already_AddRefed
On 2015-07-07 6:37 AM, Aryeh Gregor wrote: Did you check whether this actually occurs in an optimized build? C++ allows temporaries to be optimized away under some circumstances, e.g., when returning a local variable. It would make a lot of sense to me if it allowed the temporary created by a ternary operator to be optimized away. No, I never checked if it happens on an optimized build, but as C++ follows an as-if principal, which means that code has to execute as if those temporaries had been created. Unfortunately, AddRef and Release are virtual, which, I'm pretty sure, means that the compiler can't optimize them out as they may have arbitrary side effects :(. So the temporaries are probably eliminated, but the calls to AddRef and Release are probably not. I could be wrong on this though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
(Posted this reply to the wrong thread, reposting to the right one... _) One more group of defectors within Mozilla. From the DevTools coding standards[0]: - aArguments aAre the aDevil (don't use them please) Although, there are still some files in tree with the legacy style. [0] https://wiki.mozilla.org/DevTools/CodingStandards#Code_style On Tue, Jul 7, 2015 at 6:57 AM, Kartikaya Gupta kgu...@mozilla.com wrote: On Tue, Jul 7, 2015 at 9:18 AM, Honza Bambas hbam...@mozilla.com wrote: I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. That's (sorry) non-sense. In almost all cases longer methods/functions cannot be just split. It would probably make the code just much harder to read and maintain (with a lot of new arguments missing the 'a' prefix ;)) and is not necessary. Not an argument IMHO. Can you point me to a couple of examples of long functions that you think cannot be split reasonably? I'm curious to see what it looks like. Obviously functions with giant switch statements and the like are exceptions and should be treated exceptionally but I would like to see some regular functions that can't be split. Cheers, kats ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
FWIW, I did a quick poll of the people in our Gfx daily. Here are the results: For aArguments: Bas Milan Matt Kats Against aArguments: Me No strong opinion: Sotoro Lee Benoit Nical Mason -Jeff On Tue, Jul 7, 2015 at 11:12 AM, Nick Fitzgerald nfitzger...@mozilla.com wrote: (Posted this reply to the wrong thread, reposting to the right one... _) One more group of defectors within Mozilla. From the DevTools coding standards[0]: - aArguments aAre the aDevil (don't use them please) Although, there are still some files in tree with the legacy style. [0] https://wiki.mozilla.org/DevTools/CodingStandards#Code_style On Tue, Jul 7, 2015 at 6:57 AM, Kartikaya Gupta kgu...@mozilla.com wrote: On Tue, Jul 7, 2015 at 9:18 AM, Honza Bambas hbam...@mozilla.com wrote: I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. That's (sorry) non-sense. In almost all cases longer methods/functions cannot be just split. It would probably make the code just much harder to read and maintain (with a lot of new arguments missing the 'a' prefix ;)) and is not necessary. Not an argument IMHO. Can you point me to a couple of examples of long functions that you think cannot be split reasonably? I'm curious to see what it looks like. Obviously functions with giant switch statements and the like are exceptions and should be treated exceptionally but I would like to see some regular functions that can't be split. Cheers, kats ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tuesday, July 7, 2015 at 3:30:59 PM UTC-7, Birunthan Mohanathas wrote: On 7 July 2015 at 15:02, Mike Hommey m...@glandium.org wrote: On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: until the tools (and poiru) are run and make the code follow Mozilla coding style. Assuming you're talking about clang-format, that doesn't take care about anything else than whitespaces. I have a Clang tool to add the 'a' prefix, but it can be easily modified to drop the prefix should we decide to do so. I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing shadowing issues. Additionally I don't spend 50% of my time reviewing, so I'd say my opinion here (meh to aFoo) is less important. It's not an undue burden for me to include an aPrefix and if we have static analysis to check for it that would make it even less of an issue. re: refactoring, I suppose that could be an argument against the aPrefix, but then again various IDE's make this a bit easier (including Eclipse, which I believe roc is a user of). -e ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? Just FYI, Someone in Twitter mentioned that, code generated by Xcode uses this style by default. The languages are Obj-C and Swift, though. Examples like: https://github.com/search?l=objective-cq=aNotificationref=searchresultstype=Codeutf8= - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 1:03 PM, smaug sm...@welho.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. I'd like to point out that MozReview allows you to expand context when doing code reviews. This means the necessity of extra hints in naming conventions (such as aFoo) loses its importance. The argument that aFoo assists with readability, while historically accurate when applied to review tools such as Splinter that rely on patch/diff context, is thus somewhat undermined by the employment of modern code review tool. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Telemetry dashboards!
CloudFront was serving stale data, it's fixed now. Give it another try? On Tuesday, July 7, 2015 at 3:06:45 PM UTC-4, Boris Zbarsky wrote: On 7/7/15 2:26 PM, Vladan Djeric wrote: Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. When I first load https://telemetry.mozilla.org/ it says, in the console: ReferenceError: CustomSelector is not defined dashboard.js:674:5 and the spinner just keeps spinning. Clicking the Add another series button doesn't seem to work. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 3:02 PM, Mike Hommey m...@glandium.org wrote: On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: On 07/07/2015 11:45 PM, Milan Sreckovic wrote: Removing the style guide for “prefix function arguments with a” will not preclude people from naming a variable aFoo. At least the current style guide precludes people from naming non-function arguments that way, albeit indirectly. I’m trying to understand the possible outcomes of this particular conversation: a) Nothing happens. We leave a prefix in the style guide, some code ignores it, some follows it. until the tools (and poiru) are run and make the code follow Mozilla coding style. Assuming you're talking about clang-format, that doesn't take care about anything else than whitespaces. poiru built tools to automatically make all the adjustments that we prescribe in the style guide, and has been iteratively running them on various modules (thanks poiru!), so we should assume that whatever style we pick for the style guide will end up applying to all/most of our code in the not-too-distant future. This is a good thing - specifying things in the style guide but keeping the tree inconsistent on the grounds of when in Rome is the wrong approach. This was discussed to death in various threads already, and the conclusion is that we are actively moving towards a unified style in Gecko and SM. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7 July 2015 at 15:02, Mike Hommey m...@glandium.org wrote: On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: until the tools (and poiru) are run and make the code follow Mozilla coding style. Assuming you're talking about clang-format, that doesn't take care about anything else than whitespaces. I have a Clang tool to add the 'a' prefix, but it can be easily modified to drop the prefix should we decide to do so. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing shadowing issues. MSVC 2013 (which I believe is our main windows compiler right now) will error during compilation if such a shadowing issue arises. Thus, if the code compiles there, `aFoo`-`foo` is safe. I would be very surprised if GCC or Clang didn't have an equivalent option. Additionally I don't spend 50% of my time reviewing, so I'd say my opinion here (meh to aFoo) is less important. It's not an undue burden for me to include an aPrefix and if we have static analysis to check for it that would make it even less of an issue. It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. With the exception of a couple people, review is not the bottleneck. The opinions of a few over-harried reviewers should not hold undue sway over the many many devs writing code. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 07, 2015 at 05:09:57PM -0700, Gregory Szorc wrote: On Tue, Jul 7, 2015 at 1:03 PM, smaug sm...@welho.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. I'd like to point out that MozReview allows you to expand context when doing code reviews. This means the necessity of extra hints in naming conventions (such as aFoo) loses its importance. The argument that aFoo assists with readability, while historically accurate when applied to review tools such as Splinter that rely on patch/diff context, is thus somewhat undermined by the employment of modern code review tool. While mozreview helps to some degree, searching for the function declaration is not really something that is made easier by the context expansion feature it has. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 07/07/15 07:17, Eric Rescorla wrote: I am in favor of getting rid of aFoo. -Ekr P.S. At the risk of convincing people I am crazy and thus discounting my opinion above, I rather prefer foo_ to mFoo, but this seems like more a matter of taste. I agree that `aFoo` is only useful very marginally, and rather ugly. I also agree with Eric that `foo_` is somewhat nicer to read than `mFoo`, which introduces a weird cAmelCase, but I can live with it. For what it's worth, `this-foo` is also nice. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- On 7/7/2015 5:12, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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: Shutdown hangs are very common
On Monday, July 6, 2015 at 3:52:39 PM UTC-5, Kyle Huey wrote: On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen rya...@gmail.com wrote: On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform The last five logs in that bug are all hanging in QuotaClient code. I'll take a look. - Kyle Bug 1160459 was filed on the QuotaClient problem, it's a parent of the test failure bug. There's some discussion in there about the problem which you were involved in fyi. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
On Fri, Jul 3, 2015 at 6:22 PM, Michael Layzell mich...@thelayzells.com wrote: So the ternary actually causes an unnecessary AddRef/Release pair, neat. Did you check whether this actually occurs in an optimized build? C++ allows temporaries to be optimized away under some circumstances, e.g., when returning a local variable. It would make a lot of sense to me if it allowed the temporary created by a ternary operator to be optimized away. The problem here appears to be that when deciding the type of the ternary, c++ chooses nsRefPtrFoo, rather than Foo*. Adding the get() makes C++ choose the correct type for the ternary, and avoids the cast of the rvalue reference. I think it's pretty clear that nsRefPtrFoo must be the type of the ternary expression. I would be rather surprised if the type of the ternary depended on what you did with the result! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Jeff encouraged me to add more things to this thread, so I’m blaming him. So, some random thoughts. After getting paid to write code for 20+ years and then showing up at Mozilla, and seeing the a prefix, I thought “this is brilliant, how come we didn’t think of doing that before?!”, as a reasonable balance between nothing and the insanity of the full Hungarian. I find a prefix useful when I’m writing code and when I’m reading it. I have no trouble reading the code that isn’t using this convention. I don’t think I ran into a situation where only some of the arguments in the function were using the prefix (and some were not), but I can imagine that being the only situation where I’d argue that it’s confusing. In other words, as weird as it may sound, I find the prefix improving the readability, but the lack of it not hindering it. And it makes no difference to me when I’m reviewing code, which is a couple of orders of magnitude fewer times than for most people on this thread. If I was writing a new file from scratch, I’d use this convention. If I was in a file that wasn’t using it, it wouldn’t bother me. I think it would be a bad idea to force this consistency on the whole codebase (e.g., either clear it out, or put it everywhere), as I don’t think it would actually solve anything. The “consistent is good” can be taken too far, and I think this would be taking it too far. I honestly think the best thing to do here is nothing - remove it from the style guide if we don’t want to enforce it, but don’t stop me from using it. Blame Jeff for the above. — - Milan On Jul 7, 2015, at 20:41 , 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? 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. 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. ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 6:06 PM, Karl Tomlinson mozn...@karlt.net wrote: Jeff Gilbert writes: I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well? Long functions (which have poor readability anyway) generally have so much going on that the trivia of which vars are args does not seem very useful.. I do not see how `aFoo` helps here, so please expand on this. A simple variable name, such as font for example, may identify any of a number of fonts. Such simple names, without any qualifier in the name, are often used in loops, for example, because it is the most important font in the immediate context. However a simple variable may also be used in a parameter list because when looking at the parameter list it is obvious which font is relevant in the interface. That means that if font is seen in the body of a function, the first question that arises is which font? If it's named well, there should be no question which it refers to, with or without argument decoration. If the variable is called aFont then we know which font because we know what function we are in. Use aFont if it helps, just as we use iFoo and fFoo sometimes when doing conversions. Don't require it though. In particular, `newSize` is better than `aSize` when also dealing with mSize. Inferring the meaning of a variable from its status as an argument is a crutch for poor variable naming. (and adds mental load) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Jeff Gilbert writes: On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson mozn...@karlt.net wrote: 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'. I wouldn't see a problem with removing the 'a' prefix from parameter names in declarations and inline methods. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
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? 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. 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 5:13 PM, Jeff Gilbert jgilb...@mozilla.com wrote: On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing shadowing issues. MSVC 2013 (which I believe is our main windows compiler right now) will error during compilation if such a shadowing issue arises. Thus, if the code compiles there, `aFoo`-`foo` is safe. I would be very surprised if GCC or Clang didn't have an equivalent option. Additionally I don't spend 50% of my time reviewing, so I'd say my opinion here (meh to aFoo) is less important. It's not an undue burden for me to include an aPrefix and if we have static analysis to check for it that would make it even less of an issue. It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. With the exception of a couple people, review is not the bottleneck. The opinions of a few over-harried reviewers should not hold undue sway over the many many devs writing code. I somewhat disagree. There will always be fewer code reviewers than contributors. And, code reviewers tend to be more senior people. The time of a code reviewer thus tends to be more valuable than the time of the average code author. Coupled with the fact that code review is a barrier to landing, this translates to an incentive to make the lives and workflows of code reviewers as frictionless as possible. I feel strongly that the bandwidth limitations of code reviewers does dictate to some extent how code is written. For example, I feel that authors should spend extra effort to write detailed commit messages and split work into multiple, easier-to-review commits, as these can drastically reduce the time it takes for review. How much this reasoning extends to style and things like aFoo, I'm not sure. But if I hear a frequent code reviewer say X makes review easier, I tend to take that opinion more seriously than that of a non-reviewer. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 5:13 PM, Jeff Gilbert jgilb...@mozilla.com wrote: MSVC 2013 (which I believe is our main windows compiler right now) will error during compilation if such a shadowing issue arises. Thus, if the code compiles there, `aFoo`-`foo` is safe. I would be very surprised if GCC or Clang didn't have an equivalent option. They do, and dbaron mentioned them earlier. They're currently not on because there are quite a lot of warnings because there is quite a lot of shadowing occurring. (I have some experience with this thanks to bug 800659.) So I'm surprised by your claim that this is a non-issue. It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. With the exception of a couple people, review is not the bottleneck. The opinions of a few over-harried reviewers should not hold undue sway over the many many devs writing code. Reviewing code and reading code aren't that different, so let's not get hung up on the differences there. Some people like the aFoo style and find that it helps readability. It's largely a matter of personal taste; you can't just dismiss these people as being wrong. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Mon, Jul 6, 2015 at 8:26 PM, Mike Hommey m...@glandium.org wrote: The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] It's not like they have widespread use in the industry either. That is, the same reasoning could be applied to them, yet, you're stopping at aFoo. Why? mFoo and sFoo have very different scopes compared to locals, so calling them out is useful. kFoo makes it clear that the variable is constant, and has connotations regarding it being a hardcoded limit or value. Note that commonly kFoo is actually a static constant. Immutable (`const`) locals are often not kPrefixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Jeff Gilbert writes: I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well? Long functions (which have poor readability anyway) generally have so much going on that the trivia of which vars are args does not seem very useful.. I do not see how `aFoo` helps here, so please expand on this. A simple variable name, such as font for example, may identify any of a number of fonts. Such simple names, without any qualifier in the name, are often used in loops, for example, because it is the most important font in the immediate context. However a simple variable may also be used in a parameter list because when looking at the parameter list it is obvious which font is relevant in the interface. That means that if font is seen in the body of a function, the first question that arises is which font? If the variable is called aFont then we know which font because we know what function we are in. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
+1 for removing this. Gecko's use is inconsistent, and outside of Gecko code that does use it, I've never seen it used in any other codebase. I've never gone to another project and thought, I miss decorating everything in a way that changes capitalization and impairs canonical naming. Reasons for using it in the first place are suspect. None of them seem to justify the extra developer overhead or the odd variable names that result. I can't imagine we've solved some massive readability problem unique to Gecko or unsolved by other projects, or that we're catching important problems that static analysis can't find. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
+1 for removing this. Gecko's use is inconsistent, and outside of Gecko code that does use it, I've never seen it used in any other codebase. I've never gone to another project and thought, I miss decorating everything in a way that changes capitalization and impairs canonical naming. Reasons for using it in the first place are suspect. None of them seem to justify the extra developer overhead or the odd variable names that result. I can't imagine we've solved some massive readability problem unique to Gecko or unsolved by other projects, or that we're catching important problems that static analysis can't find. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
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
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/2015 15:03, Kartikaya Gupta wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in your coding environment)? All the time? I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. That's (sorry) non-sense. In almost all cases longer methods/functions cannot be just split. It would probably make the code just much harder to read and maintain (with a lot of new arguments missing the 'a' prefix ;)) and is not necessary. Not an argument IMHO. -hb- Also FWIW in the current world I do find the prefix useful when debugging in gdb, because I know I can keep going up a frame as long as I'm tracing a variable with the prefix, whereas otherwise I would have to step backwards through each frame to see where the variable is coming from. I'll probably find some way to adapt if we remove the prefix though. kats On Tue, Jul 7, 2015 at 7:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- On 7/7/2015 5:12, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 07/07/2015 05:12, Jeff Gilbert wrote: Notable works or style guides [2] which do not recommend `aFoo`: [3] [...] To add another internal datapoint the FxOS gaia codebase is mostly devoid of this style. There are some places using the m prefix for pseudo member variables (really just JS attributes) but the a prefix for arguments is quite rare, I could find only a hundred uses of it or so. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
+1 On 07/07/15 13:54, Honza Bambas wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- On 7/7/2015 5:12, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in your coding environment)? I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. Also FWIW in the current world I do find the prefix useful when debugging in gdb, because I know I can keep going up a frame as long as I'm tracing a variable with the prefix, whereas otherwise I would have to step backwards through each frame to see where the variable is coming from. I'll probably find some way to adapt if we remove the prefix though. kats On Tue, Jul 7, 2015 at 7:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important to have it and it's good we enforce it! -hb- On 7/7/2015 5:12, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 9:18 AM, Honza Bambas hbam...@mozilla.com wrote: I'd be happy to support removing the prefix if people also commit to splitting any giant functions they touch as part of the prefix removal. That's (sorry) non-sense. In almost all cases longer methods/functions cannot be just split. It would probably make the code just much harder to read and maintain (with a lot of new arguments missing the 'a' prefix ;)) and is not necessary. Not an argument IMHO. Can you point me to a couple of examples of long functions that you think cannot be split reasonably? I'm curious to see what it looks like. Obviously functions with giant switch statements and the like are exceptions and should be treated exceptionally but I would like to see some regular functions that can't be split. Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/7/15 6:17 PM, David Anderson wrote: +1 for removing this. Gecko's use is inconsistent, and outside of Gecko code that does use it, I've never seen it used in any other codebase. I've never gone to another project and thought, I miss decorating everything in a way that changes capitalization and impairs canonical naming. I don't care strongly about the naming, but this is an important point. Jeff's original post was explicit about it too, yet it keeps being overlooked. Whenever style changes are proposed, there's a lot of of knee-jerk resistance (omgchange!). It's natural. But the relative anchor point here is that the rest of the world manages to do just fine without it. And so any stylistic benefits of aFoo feel, well, overstated. [This is a problem endemic to Mozilla, beyond simple code style. We get stuck in ruts and local maxima, and become inflexible to doing things differently from how they've always been done.] Personally, for these kinds of issues, I find it useful to think about if we would _add_ the thing if it didn't already exist. And if we wouldn't, we should strongly bias towards change unless the costs are _clearly_ not worth it. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Telemetry dashboards!
*The stale file issues are fixed, please try out the new dashes!* https://telemetry.mozilla.org/ CloudFront was serving stale data and we needed to invalidate its caches (and give it enough time to complete the invalidations). On Tue, Jul 7, 2015 at 3:15 PM, Vladan Djeric vdje...@mozilla.com wrote: It looks like there is some kind of bug with propagating the changes to the (static) dashboard files in S3, somehow causing the old dash to be shown at telemetry.mozilla.org for some users. Others are reporting dashes that don't load. Apologies for the (very embarassing) technical difficulties. I'll post here again once these deployment issues are sorted out. On Tue, Jul 7, 2015 at 2:26 PM, Vladan Djeric vdje...@mozilla.com wrote: We noticed a lot of Mozillians struggle to use the Telemetry dashboards effectively. It can be difficult to interpret the graphs numbers, hard to find or filter the data, and there is a risk of making the wrong conclusions. The dashboards needed an overhaul. Anthony Zhang, our summer intern, has been working on redesigning the dashboards over the last month. Blake Winton from the UX team gave us pointers on the UI, and people around the Toronto office helped us to test the prototypes. I think we have a much more user-friendly design as result. The new dashboards are here: https://telemetry.mozilla.org I invite you to try out the new Histogram and Evolution dashes and leave your feedback here: https://etherpad.mozilla.org/new-telemetry-dash-feedback Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. FAQs: - If you'd prefer to continue to use the old dashboard, we kept it here: https://telemetry.mozilla.org/advanced/ - Anthony will soon be adding support for keyed histograms (bug 1151756) and count histograms (1172113) to the dashboards - Anthony is adding a table view to the Histogram dashboards - We also have prototype dashes connected to the new, unified Telemetry backend (histogram http://anthony-zhang.me/telemetry-dashboard/dist.html and evolution http://anthony-zhang.me/telemetry-dashboard/evo.html) - Dashboard source: https://github.com/mozilla/telemetry-dashboard/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Tuesday, June 16, 2015 at 5:12:17 PM UTC-4, Mike Hommey wrote: On Tue, Jun 16, 2015 at 04:16:13PM -0400, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. If anyone has any reasons for us not to make this change it would be good to know now. FWIW, I believe Fedora is already shipping GTK3 builds of Firefox. I depends on what our target GTK3 version would be. If, as recently suggested, we go with 3.14 as the minimum supported, that's fairly new (9 months old), and switching our builds to GTK3 would make us drop support for a lot of people that use older systems. I thought we'd be shipping both GTK2 and GTK3 builds for a while. Mike In Ubuntu, we don't have a strong preference for Gtk2 versus Gtk3, but it is important for us to support Gtk-3.4. We are obligated to keep Ubuntu 12.04 updated for a while still. So, if you don't change the current library versions on Mozilla's test machines, I'm happy. Please keep dependencies to Gtk-3.4 at latest. - chad ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
