Organizing source in namespaces.

[BigMan]

I've come to the decision to use multiple namespaces for a very
specific reason:

I like to use descriptive names of UDTs and I sometimes come up with
long UDT names (and file names too, since I name a source file after
the UDT that is defined in it, if any).

I've also noticed, however, that certain types are related more than
logically but also lexically - they start with the same word (which
happens to be the basic concept that they relate to). So, these UDTs
can be grouped together into a namespace. Thus the leading word would
drop out and become the name of the namespace. This would shorten both
names of UDTs and names and source files.

There is a little caveat, however - when I drop the leading word out I
may come up with conflicting file names. Here's why: in spite of
relating to different basic concepts the UDTs defined in those files
have other, less important, concepts in common, which, or course, come
after the name of the first concept in the name of the UDT(and source
file).

There is, of course, at least two ways out of this situation:
1) give up descriptive names; I wouldn't do that for the time being -
I'm used to them and I find them convenient; besides, if names of UDTs
get really long, I tend to shorten them to acronyms (capital first
letters of each word) despite my desire to avoid acronyms in source
code;
2) put each namespace into a separate folder; this will avoid file name
conflicts and since names of UDTs will become shorter I can get some
acronyms back to their full form;

Option 2 seems to be the best one for now. Could anyone else share some
experience or give ideas about my problem?

 

[Jonathan Mcdougall]

I've come to the decision to use multiple namespaces for a very
specific reason:

I like to use descriptive names of UDTs and I sometimes come up with
long UDT names (and file names too, since I name a source file after
the UDT that is defined in it, if any).

I've also noticed, however, that certain types are related more than
logically but also lexically - they start with the same word (which
happens to be the basic concept that they relate to). So, these UDTs
can be grouped together into a namespace. Thus the leading word would
drop out and become the name of the namespace. This would shorten both
names of UDTs and names and source files.

There is a little caveat, however - when I drop the leading word out I
may come up with conflicting file names. Here's why: in spite of
relating to different basic concepts the UDTs defined in those files
have other, less important, concepts in common, which, or course, come
after the name of the first concept in the name of the UDT(and source
file).

There is, of course, at least two ways out of this situation:
1) give up descriptive names; I wouldn't do that for the time being -
I'm used to them and I find them convenient; besides, if names of UDTs
get really long, I tend to shorten them to acronyms (capital first
letters of each word) despite my desire to avoid acronyms in source
code;
2) put each namespace into a separate folder; this will avoid file name
conflicts and since names of UDTs will become shorter I can get some
acronyms back to their full form;

Option 2 seems to be the best one for now. Could anyone else share some
experience or give ideas about my problem?

I think we all went through different phases while we learn
programming. First your programs have no structure whatsoever and you
don't understand why it should have one (it works, so..). Then you
have an incredible need of structure, you classes are named
computer::Equipment::Memory::Flash, defined in the file
~/dev/c++/projects/starting/car/src/computer/equipment/memory/flash/class_def.h.

And then you realize it doesn't really matter, as long as what you do
is consistent and practical. Are you consistent? Is your code
practical? Probably not. Try to minimize the complexity of your naming
scheme, C++ can be complex enough by itself.


Jonathan

 

[BigMan]

I must confess that you really have a point here - the code should be
consistent and practical. But organization is a prerequisite for this.
Let me illustrate this with the help of a simple example
At present one of my projects consists of 150+ files and it gets more
and more difficult for me to manage them and find manually what I need
(the IDE has hard time doing so, too). So what am I supposed to do?
Leave all those files in the same folder and in the same namespace? I
do not think this is very practical, since I tend to lose more and more
time getting my way round.

 

[BigMan]

UDT = user defined type
Sorry for having forgotten to mention this!

 

[Jonathan Mcdougall]

I must confess that you really have a point here - the code should be
consistent and practical. But organization is a prerequisite for this.
Let me illustrate this with the help of a simple example
At present one of my projects consists of 150+ files and it gets more
and more difficult for me to manage them and find manually what I need
(the IDE has hard time doing so, too). So what am I supposed to do?
Leave all those files in the same folder and in the same namespace? I
do not think this is very practical, since I tend to lose more and more
time getting my way round.

Very general answers (you may add a "most of the times" or "unless you
have a good reason" to each):

1) Quote the message you are answering to (that one is final)
2) Minimize the number of files. Don't use one header/implementation
for each class (a la Java). Group them in a more general fashion.
3) Don't nest namespaces.
4) Use short but descriptive names (acronyms may be ok)
5) Use free functions, declared in the header it relates to, instead of
member functions when you can. It greatly simplifies the naming. Don't
replace Car::start() by car_start(Car&); replace it by start(Car&) and
put it in the header. Most of the times, namespaces, headers and
overloading will prevent name clashes.
6) Change the IDE


Jonathan

 

[Capstar]

Very general answers (you may add a "most of the times" or "unless you
have a good reason" to each):

1) Quote the message you are answering to (that one is final)
2) Minimize the number of files. Don't use one header/implementation
for each class (a la Java). Group them in a more general fashion.
3) Don't nest namespaces.
4) Use short but descriptive names (acronyms may be ok)
5) Use free functions, declared in the header it relates to, instead of
member functions when you can. It greatly simplifies the naming. Don't
replace Car::start() by car_start(Car&); replace it by start(Car&) and
put it in the header. Most of the times, namespaces, headers and
overloading will prevent name clashes.
6) Change the IDE


Jonathan

Hi,

I don't get point 5. Why would you use free functions instead of class
methods? I don't see why it simplifies naming.

Using start( myCar ) instead of myCar.start() seems a bit C-ish to me.
I do see however that in C you probably need to use car_start() since
you also might have a plane_start() or something, and in C++ they can
both be called start(). But still I could do myCar.start() or
myPlane.start().

But please tell me what I'm missing or when this construct is preferred,
cause I'm certainly not too old to learn.

Mark

 

[Jonathan Mcdougall]

I don't get point 5. Why would you use free functions instead of class
methods? I don't see why it simplifies naming.

Because these function are not called Car::start() anymore, only
start(). Particularily, using pointer to functions is quite simpler
than member function pointers (from a my-names-are-too-long pov, of
course).

Using start( myCar ) instead of myCar.start() seems a bit C-ish to me.

Well I've taken the habit (like many) to only make a function a member
if it needs access to its internal representation. It certainly don't
look C-ish to me.

But please tell me what I'm missing or when this construct is preferred,
cause I'm certainly not too old to learn.

This construct is not "preferred", it is simply an alternative. I tend
to prefer it and it seems like it could help the op's problem. That`s
why I proposed it.


Jonathan