[
https://issues.apache.org/jira/browse/MESOS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271847#comment-14271847
]
Timothy Chen commented on MESOS-2211:
-------------------------------------
I'm ok as long as it's consistent, we certainly don't follow this pattern in
our mesos source code headers.
I don't know is there a preferrable or gold standard about this, but feels odd
to have two different standards for public includes and in mesos source code.
The problem with our own code is that we have 5 levels deep
(slave/containerizer/isolator/cgroups/cpushare.hpp), I don't think it makes
sense to put all of that into the guard name?
> Include guard naming fixup
> --------------------------
>
> Key: MESOS-2211
> URL: https://issues.apache.org/jira/browse/MESOS-2211
> Project: Mesos
> Issue Type: Bug
> Reporter: Till Toenshoff
> Priority: Trivial
> Labels: newbie
>
> Triggered by a comment in a review request, I noticed that we currently have
> no consistent style for naming include guards.
> Examples:
> include/mesos/resources.hpp: {{#define __RESOURCES_HPP__}}
> include/mesos/executor.hpp: {{#define __MESOS_EXECUTOR_HPP__}}
> include/mesos/mesos.hpp: {{#define __MESOS_HPP__}}
> I think the **right** way would be stating the path and include file name
> within the guard, so the above at fault become:
> include/mesos/resources.hpp: {{#define __MESOS_RESOURCES_HPP__}}
> include/mesos/mesos.hpp: {{#define __MESOS_MESOS_HPP__}}
> Everything from include/XXX should have a __XXX_ prefix in its guard name,
> anything from src/XXX should have a __XXX_ prefix. This should also apply to
> multiple folder levels; e.g. include/XXX/YYY/FOO should have a __XXX_YYY_FOO
> prefix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
