On Aug 4, 2010, at 1:29 AM, Nikolas Zimmermann wrote:
> 1. namespace closing brace
> It was discussed in
> http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with no
> real result.
>
> When writing headers, do we need the "// namespace Foo" comment after the
> namespace closing brace? I think it's visual noise and would like to see a
> style rule that forbids it.
> (A rule that says we need this would also be fine with me, as long as we
> write it down. But I'd vote for removing those comments, I don't trust them
> anyways, if I'm unsure.)
>
> namespace WebCore {
> ...
> } // namespace WebCore
My personal preference: We should omit it.
> 2. ENABLE(FOO) #endif comments
>
> #if ENABLE(FOO)
> ..
> #endif // ENABLE(FOO)
>
> Shall we remove the comment, or require it explicitely in the style rules?
My personal preference: We should omit it.
> 3. Inclusion order
>
> Say Foo.h is guarded with ENABLE(FOO) macros
> Foo.h:
> #if ENABLE(FOO)
> namespace WebCore {
>
> class Foo...
>
> }
> #endif
>
> What's the correct inclusion order in Foo.cpp:
> #include "config.h"
> #include "Foo.h"
>
> #if ENABLE(FOO)
> ..
> #endif
>
> or
>
> #include "config.h"
> #include "Foo.h"
>
> #if ENABLE(FOO)
> ..
> #endif
>
> (I think the former, as it makes no sense to process the header, if I already
> know it's enclosed in ENABLE(FOO) blocks)
My personal preference: The latter. One of the main reasons we include "Foo.h"
first in "Foo.cpp" is to test that the header has the proper includes to be
used standalone. It may be useful to do that test even if the header is
supposed to be wrapped entirely in ENABLE(FOO).
But this is a close call. I’d be happy either way.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
