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