From: Christophe de Dinechin <dinechin@xxxxxxxxxx> This attempts to find a wording that takes into account the existing practice, notably in the server. Signed-off-by: Christophe de Dinechin <dinechin@xxxxxxxxxx> --- docs/spice_style.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/docs/spice_style.txt b/docs/spice_style.txt index c28d7be3..4c29a410 100644 --- a/docs/spice_style.txt +++ b/docs/spice_style.txt @@ -432,12 +432,22 @@ Headers should be protected against multiple inclusion using a macro that contai ... -#endif // MY_MODULE_H +#endif /* MY_MODULE_H */ ---- -The macro may include additional information, e.g. a component. For example a file generally referenced as foo/bar.h could use a FOO_BAR_H macro. +The macro may include additional information, e.g. a component. For +example a file generally referenced as foo/bar.h could use a FOO_BAR_H +macro. + +Historically, some headers added underscores liberally, +e.g. MY_MODULE_H_. This is neither necessary nor discouraged, although +as a reminder, a leading underscore followed by a capital letter is +reserved for the implementation and should not be used, so +_MY_MODULE_H is, technically speaking, invalid C. + +C++ headers and headers in new components should use // for the #endif comment. +The server code consistently uses /* */ for the #endif comment, keep it that way. -Historically, some headers added underscores liberally, e.g. MY_MODULE_H_. This is neither necessary nor discouraged, although as a reminder, a leading underscore followed by a capital letter is reserved for the implementation and should not be used, so _MY_MODULE_H is, technically speaking, invalid C. Header inclusion ---------------- -- 2.13.5 (Apple Git-94) _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel