Re: Coding style: Making the `e` prefix for enum variants not mandatory?
I don't believe e-prefix adds sufficient value. Mutable statics *must* always be s-prefixed. If this is not the case I will gladly bring the codebase into compliance. On Fri, Jun 29, 2018 at 11:36 AM, smaug wrote: > On 06/29/2018 05:58 PM, Boris Zbarsky wrote: >> >> On 6/29/18 10:30 AM, Nathan Froyd wrote: >>> >>> Given the language-required qualification for >>> `enum class` and a more Rust-alike syntax, I would feel comfortable >>> with saying CamelCase `enum class` is the way to go. >> >> >> For what it's worth, I agree. The point of the "e" prefix is to highlight >> that you have an enumeration and add some poor-man's namespacing for a >> potentially large number of common-looking names, and the language-required >> qualification already handles both of those. >> > > That works if we're consistently naming static variables and such using > s-prefix etc, so that > class Foo1 > { > static int sBar; > }; > Foo1::sBar > > is clearly different to > enum class Foo2 > { > Bar > }; > > Foo2::Bar > > > (personally I'd still prefer using e-prefix always with enums, class or not. > Foo1::sBar vs Foo2::eBar is easier to distinguish than Foo1::sBar vs > Foo2::Bar) > > -Olli > > > > >> -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: Coding style: Making the `e` prefix for enum variants not mandatory?
On 29/06/2018 16:58, Boris Zbarsky wrote: On 6/29/18 10:30 AM, Nathan Froyd wrote: Given the language-required qualification for `enum class` and a more Rust-alike syntax, I would feel comfortable with saying CamelCase `enum class` is the way to go. For what it's worth, I agree. The point of the "e" prefix is to highlight that you have an enumeration and add some poor-man's namespacing for a potentially large number of common-looking names, and the language-required qualification already handles both of those. +1.. Would certainly be disappointed with an ALL_CAPS (being myself a user of kCamelCase) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
On 6/29/18 10:30 AM, Nathan Froyd wrote: Given the language-required qualification for `enum class` and a more Rust-alike syntax, I would feel comfortable with saying CamelCase `enum class` is the way to go. For what it's worth, I agree. The point of the "e" prefix is to highlight that you have an enumeration and add some poor-man's namespacing for a potentially large number of common-looking names, and the language-required qualification already handles both of those. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Making the `e` prefix for enum variants not mandatory?
On Thu, Jun 28, 2018 at 7:35 PM, Emilio Cobos Álvarez wrote: > Oh, I didn't realize that those peers were the only ones to be able to > update the style guide, sorry. I guess it makes sense. > > I can revert the change if needed and try to get sign-off from some of > those. > > Apologies again, I just followed the procedure that was followed in the > previous thread to add the rule. Let me know if you want that change > reverted and I'll happily do so. My sense, after grepping through the code for "enum [A-Z].* \{" (that is, ignoring `enum class`, since those are effectively prefixed by the language) and eyeballing the results is that ALL_CAPS and e-prefixed enums are more common than CamelCase. Commands: # rough approximations only! # enums defined on a single line git grep -E 'enum [A-Z].* \{[^}]+\}' -- '*.[ch]*' |grep -v -e 'gfx/skia' -e 'media/webrtc' |less # multi-line enums; -A 1 so we can see the style of the first enum git grep -A 1 -E 'enum [A-Z].* \{' -- '*.[ch]*' |grep -v $(for p in $(cat tools/rewriting/ThirdPartyPaths.txt); do echo -e \\x2de $p; done) |less This exercise was not an exhaustive analysis by any means. (If somebody was going to be exhaustive about this, I think it'd be interesting to try and consider whether the enums are at global scope or at class scope, since using class scope enums outside the class naturally requires qualifying them with the class name.) Based on this, I think it's reasonable to say that e-prefixing or ALL_CAPS for (non-`enum class`) enums is the preferred style. For `enum class`, we (of course) do everything, but I think CamelCase is *slightly* more common. Given the language-required qualification for `enum class` and a more Rust-alike syntax, I would feel comfortable with saying CamelCase `enum class` is the way to go. Objections? (Almost certainly? ;) -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust crate approval
On Thu, Jun 28, 2018 at 11:42 PM, Nathan Froyd wrote: > We have generally trusted people to use good judgement in what they > use and how much review is required. Accordingly, I think you should > request review from the people who would normally review your code, > and if you have concerns about specific crates that are being > vendored, you should call those crates out as needing especial review. > If you or your reviewers think such reviews fall outside of your > comfort zone/area of expertise/Rust capabilities, please flag myself > or Ehsan, and we will work on finding people to help. > I know that enumerating badness is never a comprehensive solution; but maybe there could be a wiki page we could point people to for things that indicate something is doing something scary in Rust? This might let us crowd-source these reviews in a safer manner. For example, what would I look for in a crate to see if it was: - Adjusting memory permissions - Reading/writing to disk - Performing unsafe C/C++ pointer stuff - Performing network connections of any type - Calling out to syscalls or other kernel functions (especially win32k.sys functions on Windows) - (whatever else you can think of...) -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform