[RFC] Solid and use of namespaces

Frans Englich englich at kde.org
Sun May 21 17:53:26 BST 2006


On Saturday 20 May 2006 23:27, Kevin Ottens wrote:
> Hello list,
>
> As some of you already know, I'm working on Solid [S], and the current
> classes are in their own namespace (Solid).
>
> The current code is the most "neutral" part, it handles the hardware
> discovery. I'm planning to add more specialized classes to handle specific
> tasks, namely network and power management.
>
> Since my current idea is to put those more specialized classes in their own
> subnamespaces, I'm posting here to be sure the solution I'll choose
> regarding namespaces won't get in the way of application developers.

Namespaces are invaluable, as any other modularization mechanism, when needed. 
However, just as how applying abstraction patterns and centralizing code can 
lead to "overkill" and too heavy code when it's not needed, namespaces can 
clutter.

I personally try to use namespaces on a per-project level. For example, for a 
project of about 30 000 lines of code(about 400 classes), I have two 
namespaces. One for the project itself, and another for all debugging 
utilities/libraries which is almost a project in itself. I'd say that that a 
handful of classes belong together, isn't enough for a namespace(which seems 
to be the case of your Power/Network).

However, one shouldn't go blind on C++ namespaces, there's other alternatives 
to keeping code readable, modularized and organized:

* Modularize with directory structure
* Focus on good naming of the classes, make it clear they belong together, and 
that it's difficult to associate them with something else
* Group classes, types, and so on, in Doxygen groups with @defgroup and 
@ingroup:
http://www.stack.nl/~dimitri/doxygen/commands.html#cmddefgroup
http://www.stack.nl/~dimitri/doxygen/commands.html#cmdingroup

I think groups works well for, ehum, groups/sets of classes that belong 
together. However, I'm sure they can be abused too. I once used nested 
groups, and it was simply overkill and led to extra work.


Cheers,

		Frans





More information about the kde-core-devel mailing list