Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

namespace clutter #65

Open
GoogleCodeExporter opened this issue Apr 7, 2015 · 2 comments
Open

namespace clutter #65

GoogleCodeExporter opened this issue Apr 7, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

I'm starting to notice an anti-pattern which is cluttering up a lot of 
ros-industrial code.  Each header file is in its own namespace, making the 
imports too long to specify inline.  Thus, the pattern is to import every 
header file with the "using namespace industrial::message_handler;", a practice 
which ends up defeating the point of namespaces almost entirely.  How about 
instead we just reduce all namespaces to only "industrial" and use them inline.

Original issue reported on code.google.com by [email protected] on 23 May 2013 at 5:10

@GoogleCodeExporter
Copy link
Author

Something like "rosi" or "rosind" might also be shorter and more descriptive.

Original comment by [email protected] on 23 May 2013 at 5:11

@GoogleCodeExporter
Copy link
Author

The namespace convention was taken from the ros C++ style guide ( 
http://ros.org/wiki/CppStyleGuide#Namespaces-1 ) and based on an example within 
the ROS libraries (although I forget which one).  I agree that this causes some 
physical code clutter.  Class namespaces allow complicated class files to be 
encapsulated as well, so there is some merit to using them.  
The main reason not to make such a change is that it would touch lots of code 
within ROS-Industrial and anybody else's code that depends on ours.  From a 
user perspective, such a change would break their code without adding any new 
functionality.  There is room for discussion, but I think the effect on the end 
user should be the highest consideration.

Original comment by [email protected] on 23 May 2013 at 6:49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant