Re: [webkit-dev] Style question: static, protected, or public members
On Sun, Jun 13, 2010 at 12:46 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 4, 2010, at 3:54 PM, Joe Mason wrote: I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. I think file-scope static globals don't need a prefix. In the few cases of globals with extern linkage, I think a prefix would make them needlessly unpleasant to use. HTMLNames.h is one of the most prominent examples. I don't think we'd want to write g_divTag and g_widthAttr instead of divTag and widthAttr. For what it's worth, I think having a special prefix has benefits beyond conflicts when linking. I agree 100% with what Joe said. (That said: if there isn't a lot of support for this, I don't think anything should change...but I figured I'd throw it out there in case others agreed.) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On Jun 4, 2010, at 3:54 PM, Joe Mason wrote: I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. I think file-scope static globals don't need a prefix. In the few cases of globals with extern linkage, I think a prefix would make them needlessly unpleasant to use. HTMLNames.h is one of the most prominent examples. I don't think we'd want to write g_divTag and g_widthAttr instead of divTag and widthAttr. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. Joe -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Darin Adler Sent: Wednesday, June 02, 2010 1:03 PM To: Eric Seidel Cc: WebKit Development Subject: Re: [webkit-dev] Style question: static, protected,or public members On Jun 1, 2010, at 10:09 PM, Eric Seidel wrote: Let me summarize to see if I understand what should be updated in the style guide/check-webkit-style: Class static member variables should have an s_ prefix. Protected and public member variables should be disallowed. Private member variables should have an m_ prefix. Struct member variables should have no prefix. Yes, I think that's what we discussed. While I don't love the s_ prefix, I didn't love the m_ one either, and I got used to it. What about global statics? Currently I believe most have no prefix. Some have k or g. We didn't discuss global variables outside of a class. If we decided to start using a prefix, I'd suggest g_ but I don't think we need one. What do other people think? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On Jun 1, 2010, at 10:09 PM, Eric Seidel wrote: Let me summarize to see if I understand what should be updated in the style guide/check-webkit-style: Class static member variables should have an s_ prefix. Protected and public member variables should be disallowed. Private member variables should have an m_ prefix. Struct member variables should have no prefix. Yes, I think that’s what we discussed. While I don’t love the “s_” prefix, I didn’t love the “m_” one either, and I got used to it. What about global statics? Currently I believe most have no prefix. Some have k or g. We didn’t discuss global variables outside of a class. If we decided to start using a prefix, I’d suggest “g_” but I don’t think we need one. What do other people think? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
Let me summarize to see if I understand what should be updated in the style guide/check-webkit-style: Class static member variables should have an s_ prefix. Protected and public member variables should be disallowed. Private member variables should have an m_ prefix. Struct member variables should have no prefix. Did I understand correctly? What about global statics? Currently I believe most have no prefix. Some have k or g. -eric On Tue, May 25, 2010 at 9:44 AM, Darin Adler da...@apple.com wrote: On May 25, 2010, at 3:05 AM, TAMURA, Kent wrote: Generally speaking I suggest we do not use the m_ prefix for the members of structs. And I suggest that classes with public data members be structs instead of classes. Classes that have public data members only for historical reasons should be changed so the data members are not public. We should talk some specific examples. As for protected data members, many classes use m_ prefix. I found protected members without m_ in HTMLTableCellElement and HTMLTableColElement. I guess they are legacy code and we should use m_ for protected members too. Older classes did not use the m_ prefix consistently. Public and protected members were a little slower to get changed than others because they affected more source files. We want to use m_ for all non-static data members, but data members should also be private. Generally speaking, protected data members should be avoided entirely. Existing protected data members should generally be replaced with private data members and we can add protected accessor functions as needed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
2010/5/25 Darin Adler da...@apple.com On May 20, 2010, at 8:54 PM, TAMURA, Kent wrote: What's the naming rule for non-const static members? Some classes give s_ prefixes: WebCore/page/DOMTimer.h: static double s_minTimerInterval; WebCore/page/GeolocationPositionCache.h: static int s_instances; FrameView gives s prefix: WebCore/page/FrameView.h: static double sCurrentPaintTimeStamp; // used for detecting decoded resource thrash in the cache Settings gives g prefix: WebCore/page/Settings.h: static bool gShouldPaintNativeControls; WebCore/page/Settings.h: static bool gShouldUseHighResolutionTimers; If we have to use a prefix for this, I suggest the s_ prefix. I think s_ is reasonable. And what about public and protected members? The style guide has no exceptions for them, so I think they should have m_. But many classes in WebCore don't use m_ for public members. Generally speaking I suggest we do not use the m_ prefix for the members of structs. And I suggest that classes with public data members be structs instead of classes. Classes that have public data members only for historical reasons should be changed so the data members are not public. We should talk some specific examples. ok, public data members in classes should be changed. As for protected data members, many classes use m_ prefix. I found protected members without m_ in HTMLTableCellElement and HTMLTableColElement. I guess they are legacy code and we should use m_ for protected members too. -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On May 25, 2010, at 3:05 AM, TAMURA, Kent wrote: Generally speaking I suggest we do not use the m_ prefix for the members of structs. And I suggest that classes with public data members be structs instead of classes. Classes that have public data members only for historical reasons should be changed so the data members are not public. We should talk some specific examples. As for protected data members, many classes use m_ prefix. I found protected members without m_ in HTMLTableCellElement and HTMLTableColElement. I guess they are legacy code and we should use m_ for protected members too. Older classes did not use the m_ prefix consistently. Public and protected members were a little slower to get changed than others because they affected more source files. We want to use m_ for all non-static data members, but data members should also be private. Generally speaking, protected data members should be avoided entirely. Existing protected data members should generally be replaced with private data members and we can add protected accessor functions as needed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Style question: static, protected, or public members
What's the naming rule for non-const static members? Some classes give s_ prefixes: WebCore/page/DOMTimer.h:static double s_minTimerInterval; WebCore/page/GeolocationPositionCache.h:static int s_instances; FrameView gives s prefix: WebCore/page/FrameView.h:static double sCurrentPaintTimeStamp; // used for detecting decoded resource thrash in the cache Settings gives g prefix: WebCore/page/Settings.h:static bool gShouldPaintNativeControls; WebCore/page/Settings.h:static bool gShouldUseHighResolutionTimers; And what about public and protected members? The style guide has no exceptions for them, so I think they should have m_. But many classes in WebCore don't use m_ for public members. -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
