Hi, Is there an established naming convention for enum names in Boost? I don't see anything truly consistent. Consider this: enum eGrays { eBlack, eDarkGray, eGray, eLightGray, eWhite }; Is this commonly accepted by the Boost community? If not, what alternative naming for the above would you propose? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: 14 April 2008 08:25 To: boost@lists.boost.org Subject: [boost] Enum naming conventions
Hi,
Is there an established naming convention for enum names in Boost? I don't see anything truly consistent.
Consider this:
enum eGrays { eBlack, eDarkGray, eGray, eLightGray, eWhite };
Is this commonly accepted by the Boost community? If not, what alternative naming for the above would you propose?
Jake Voytko faced a similar, but more complicated difficulty with naming SVG colors // ----------------------------------------------------------------- // Deals with colors that have special names. The reason that the // underscore separator convention does not match the normal Boost format // is that these names that are specified by the SVG standard. // http://www.w3.org/TR/SVG/types.html#ColorKeywords // tan is also renamed to tanned to avoid clash with function tan in math.h // ----------------------------------------------------------------- enum svg_color_constant { aliceblue, antiquewhite, aqua, aquamarine, azure, beige, bisque, black, blanchedalmond, blue, blueviolet, brown, <... snipped> skyblue, slateblue, slategray, slategrey, snow, springgreen, steelblue, <and things got worse when we got to tan! // tan, // Note that tan would clash with geometric tan in math.h! global names are evil! tanned, teal, thistle, tomato, turquoise, violet, ... I don't think Boost have even *banned* camel mode - just deprecated it. So enum grays { gray_black, gray_dark, gray, gray_light...} or enum grays {black_gray, dark_gray, gray_gray, light_gray...} would both seem only a little longer and *much* easier to read? Or is it a stronger 'this is an enum' marker that you are trying to achieve? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Hi, Paul A Bristow wrote:
I don't think Boost have even *banned* camel mode - just deprecated it.
Which for reviewers of new or candidate libraries is (should be) effectively the same.
So
enum grays { gray_black, gray_dark, gray, gray_light...}
or
enum grays {black_gray, dark_gray, gray_gray, light_gray...}
would both seem only a little longer and *much* easier to read?
Yes.
Or is it a stronger 'this is an enum' marker that you are trying to achieve?
The marker (eSomething) was used in the project together with CamelCase for classes and functions. It worked very well as far as readability is concerned, but after moving everything to lowercase_with_underscores the enum names now look like eForeigners. Thanks for your response. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
----- Original Message ----- From: "Paul A Bristow" <pbristow@hetp.u-net.com> To: <boost@lists.boost.org> Sent: Monday, April 14, 2008 11:26 AM Subject: Re: [boost] Enum naming conventions
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: 14 April 2008 08:25 To: boost@lists.boost.org Subject: [boost] Enum naming conventions
Hi,
Is there an established naming convention for enum names in Boost? I don't see anything truly consistent.
Consider this:
enum eGrays { eBlack, eDarkGray, eGray, eLightGray, eWhite };
Is this commonly accepted by the Boost community? If not, what alternative naming for the above would you propose?
Jake Voytko faced a similar, but more complicated difficulty with naming SVG colors
// ----------------------------------------------------------------- // Deals with colors that have special names. The reason that the // underscore separator convention does not match the normal Boost format // is that these names that are specified by the SVG standard. // http://www.w3.org/TR/SVG/types.html#ColorKeywords // tan is also renamed to tanned to avoid clash with function tan in math.h // ----------------------------------------------------------------- enum svg_color_constant { aliceblue, antiquewhite, aqua, aquamarine, azure, beige, bisque, black, blanchedalmond, blue, blueviolet, brown, <... snipped> skyblue, slateblue, slategray, slategrey, snow, springgreen, steelblue, <and things got worse when we got to tan! // tan, // Note that tan would clash with geometric tan in math.h! global names are evil! tanned, teal, thistle, tomato, turquoise, violet, ...
I don't think Boost have even *banned* camel mode - just deprecated it.
So
enum grays { gray_black, gray_dark, gray, gray_light...}
or
enum grays {black_gray, dark_gray, gray_gray, light_gray...}
would both seem only a little longer and *much* easier to read?
Or is it a stronger 'this is an enum' marker that you are trying to achieve?
Paul
In C++0x enuma have its own namespace. why not emulate this with namespace. There is a lot of enums in boost following this. namespace grays { enum type { black, dark, gray, light...}; } The declaration of a variable is a little bit artificial, ... grays::type v; The enumeration follows the C++0x syntax. v= grays::back; When moving to C++0x you could do a replacement of grays::type and declare it as before enum type { black, dark, gray, light...}; _____________________ Vicente Juan Botet Escriba
vicente.botet wrote:
In C++0x enuma have its own namespace. why not emulate this with namespace. There is a lot of enums in boost following this.
namespace grays { enum type { black, dark, gray, light...}; }
The declaration of a variable is a little bit artificial, ... grays::type v;
The enumeration follows the C++0x syntax. v= grays::back;
When moving to C++0x you could do a replacement of grays::type and declare it as before enum type { black, dark, gray, light...};
I've always found the following CRTP quite helpful in those cases: ---------------------------------------------------------------------- template<typename Derived, typename ValueType = int> class Enumeration { public: typedef ValueType value_type; public: value_type value() const { return m_Value; } friend bool operator<(Derived const& left, Derived const& right) { return (left.value() < right.value()); } friend bool operator==(Derived const& left, Derived const& right) { return (left.value() == right.value()); } friend bool operator!=(Derived const& left, Derived const& right) { return !(left == right); } friend bool operator<=(Derived const& left, Derived const& right) { return !(right < left); } friend bool operator>(Derived const& left, Derived const& right) { return (right < left); } friend bool operator>=(Derived const& left, Derived const& right) { return !(left < right); } protected: Enumeration(value_type const value) : m_Value(value) {} private: value_type m_Value; }; ---------------------------------------------------------------------- Which can the be used like this: ---------------------------------------------------------------------- struct Color : Enumeration<Color> { enum _Domain { red, green, blue }; // Intentionally non-explicit Color(_Domain const value) : Enumeration<Color>(value) {} }; void func(Color const color) { // ... } int main(int, char**) { Color myColor = Color::red; func(Color::blue); return 0; }; ---------------------------------------------------------------------- Best regards, Kimon
participants (4)
-
Kimon Hoffmann -
Maciej Sobczak -
Paul A Bristow -
vicente.botet