Cppcoreguidelines: namespace and classnames

[luopeien]

Have any guide on how to name class names if used with namespaces?

For example:
namespace company {
namespace project {
namespace http {
class Server;
class Client;
class Options;
}}}

or this way:
namespace company {
namespace project {
class HttpServer;
class HttpClient;
class HttpOptions;
}}}

Someone may prefer to use more levels of namespaces and use short class names, as simple as: Options, Server, Client. Is there a general guide about this?

[grahamreeds]

Firstly I wouldn't have company as a namespace. It is a pain to type
though intellisense reduces this pain to a dull ache. Also what happens
when the company is bought/merged? ie: HP/Compaq, Sun/Oracle.

For your actual question I would, and have, used the former. A namespace is
to group things that are related. Having http in the title costs little but
is redundant information.

GR

Sent from my Nexus 5.

On 6 Sep 2016 11:28 a.m., "peien luo" [email protected] wrote:

Have any guide on how to name class names if used with namespaces?

For example:
namespace company {
namespace project {
namespace http {
class Server;
class Client;
class Options;
}}}

or this way:
namespace company {
namespace project {
class HttpServer;
class HttpClient;
class HttpOptions;
}}}

Someone may prefer to use more levels of namespaces and use short class
names, as simple as: Options, Server, Client. Is there a general guide
about this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/isocpp/CppCoreGuidelines/issues/723, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AEy9nIQHf08gxJL8Ag_I0xlJ_gzpwFYwks5qnUBBgaJpZM4J1sHh
.

[KrisTC]

Companies do change name, but having a slightly out of date namespace is less of a problem than having clashing project names. How many companies have something called HttpLib at the project level? When using your own company types they will all be in the same namespace so you don't need to use it everywhere so I am not sure I agree with @grahamreeds comment about 'Its a pain to type'.

Also this may be just personal taste but I prefer calling it HttpServer rather than http::Server. I quite often use tools like Visual Assist and similar tools and use 'Open File in solution...' Lots of classes / files can legitimately be called (Client, Server, Options).

Also in header files, you should not use 'using namespace' to avoid polluting name resolution; this results in needing the full name in headers. this is more to type with namespace http::server vs. HttpServer. The not putting 'using namespace _my_namespace_' is a rule in my company but I haven't seen it in core guidelines have I missed it?

[tamaskenez]

Also in header files, you should not use 'using namespace' to avoid polluting name resolution; this results in needing the full name in headers

You should not use using namespace in the global scope but I don't see any wrong with establishing a set of used types in your own namespace:

my_header.h:

namespace my_namespace {
    using std::string;
    void my_fun(const string &x);
}

Of course, that way std::string will be part of your API.

[KrisTC]

@tamaskenez, Nice clarification. I have just found a load of discussion on this under: https://github.com/isocpp/CppCoreGuidelines/issues/391

[BjarneStroustrup]

On the question that started this issue: We don't see any general and universally acceptable way of naming classes and namespaces, so we will not make a recommendation (leaving the issue to individual projects)

[galik]

There is one issue that has cropped up a few times in other threads which is when two projects share the same namespace. For example:

// mathlib.h

namespace math {

// various typical math functions

} // namespace math

And a different math library:

// libmath.h

namespace math {

// various typical math functions

} // namespace math

Leading to:

#include <mathlib.h>
#include <libmath.h>

// How to disambiguate these?

The only way I see is for libraries to have a unique outer namespace to give users the power to deal with any conflicts:

// mathlib.h

namespace vendor_one_unique_name {
namespace math {

// various typical math functions

} // namespace math
} // namespace vendor_one_unique_name

And a different math library:

// libmath.h

namespace vendor_two_unique_name {
namespace math {

// various typical math functions

} // namespace math
} // namespace vendor_two_unique_name

Leading to:

#include <mathlib.h>
#include <libmath.h>

// now we can do something about this
namespace math1 = vendor_one_unique_name::math;
namespace math2 = vendor_two_unique_name::math;

// Or even something pick'n'mix like this?
namespace math {
    using vendor_one_unique_name::math::trigonometry;
    using vendor_two_unique_name::math::mechanics;
}

The namespace tools built into the language can now be used to control potential conflicts between libraries and to protect application code form potentially hard to spot name conflicts. After all, even if one of the library names does conflict, it won't always flag an error. It may silently do the wrong thing.

So maybe it would be worth considering, as a suggestion, that library projects provide a surrounding unique_as_possible namespace?

[jwakely]

Do people really need that stated? Isn't it obvious that picking highly generic names for your top-level namespaces is likely to cause clashes?

The more time spent documenting obvious things like "don't use bad names" the less time there is for developing sensible guidelines. And it gets harder for readers to find the useful material if it's surrounded by handholding advice.

[BjarneStroustrup]

jwakely: +1
Also, remember we are aiming for sensible advice for millions, not ideal advice for dozens. That's non-trivial.