>   People say "it would reduce readability/maintainability", "many experts
 > advocate the usage of 'using' statements". Could some rational arguments
 > explaining these claims be given?

Interestingly enough, for the couple of years I hung around on the Ada 
newsgroups, this was one of the ongoing repeated flamefest topics. Some 
people thought it was always dangerous to use the Ada equivalent of 
importing a namespace, some people thought it was reasonable for namespaces 
equivalent to the sorts of things you find in std:: (like variable-length 
string managment, etc).  Most people agreed it was OK if you limited the 
scope of the import to (for example) one routine at a time. Of course, in 
Ada you can nest procedures inside other procedures, so that was less of a 
hardship than it would be in C++.

FWIW, I don't remember anyone on the Ada groups ever providing actual 
scientific evidence one way or the other either. And I'd think if there's 
any programming language where that sort of evidence would be around, it 
would likely be Ada.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
>  >   People say "it would reduce readability/maintainability", "many experts
>  > advocate the usage of 'using' statements". Could some rational arguments
>  > explaining these claims be given?

> Interestingly enough, for the couple of years I hung around on the Ada 
> newsgroups, this was one of the ongoing repeated flamefest topics. Some 
> people thought it was always dangerous to use the Ada equivalent of 
> importing a namespace, some people thought it was reasonable for namespaces 
> equivalent to the sorts of things you find in std:: (like variable-length 
> string managment, etc).  Most people agreed it was OK if you limited the 
> scope of the import to (for example) one routine at a time. Of course, in 
> Ada you can nest procedures inside other procedures, so that was less of a 
> hardship than it would be in C++.

> FWIW, I don't remember anyone on the Ada groups ever providing actual 
> scientific evidence one way or the other either. And I'd think if there's 
> any programming language where that sort of evidence would be around, it 
> would likely be Ada.

  "using namespace" statements might in some cases be justifiable if the
name of the namespace is very long and/or there are many nested namespaces
(which is sometimes the case). However, a common recommendation in these
cases is to use namespace aliases instead (which is possible in C++). It's
a bit like a typedef, but for namespaces. For example:

    namespace bid = boost::io::detail;

  After that you can use 'bid::' instead of 'boost::io::detail::' as the
prefix for names in that namespace.

  However, this should only be considered as a convenience shortcut, similar
to using a typedef to shorten very long type definitions. Abusing it to the
extreme should be avoided.

  Personally I have never understood the aversion many people have against
the 'std' namespace. It's very short, so it's not a question of it being
laborious to write. And as I have argued elsewhere, using the namespace
prefixes actually makes the code easier to read and understand, while
avoiding them can sometimes make the code more obfuscated, requiring more
work to understand what is it doing.

-- 
                                                          - Warp

Post a reply to this message

>  "using namespace" statements might in some cases be justifiable if the
> name of the namespace is very long and/or there are many nested namespaces
> (which is sometimes the case). However, a common recommendation in these
> cases is to use namespace aliases instead (which is possible in C++). It's
> a bit like a typedef, but for namespaces. For example:
>
>    namespace bid = boost::io::detail;
>
>  After that you can use 'bid::' instead of 'boost::io::detail::' as the
> prefix for names in that namespace.

In that case what is the benefit of using 'bid::' to qualify every type 
rather than simply putting "using namespace boost::io::detail" at the top?

The disadvantages are obvious - having to type bid:: before every type 
(annoying if almost every line contains several types from that namespace) 
and your code looks very "unoptimised" when the same string is repeated a 
huge number of times.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  "using namespace" statements might in some cases be justifiable if the
> > name of the namespace is very long and/or there are many nested namespaces
> > (which is sometimes the case). However, a common recommendation in these
> > cases is to use namespace aliases instead (which is possible in C++). It's
> > a bit like a typedef, but for namespaces. For example:
> >
> >    namespace bid = boost::io::detail;
> >
> >  After that you can use 'bid::' instead of 'boost::io::detail::' as the
> > prefix for names in that namespace.

> In that case what is the benefit of using 'bid::' to qualify every type 
> rather than simply putting "using namespace boost::io::detail" at the top?

  1) It makes it clear where the names are coming from (which is especially
important if you are using names from several different namespaces, as eg.
boost has quite many of them). The namespace prefix makes it much easier
to recognize a name if you know it, or if you don't know it, it makes it
much easier to know where to look for documentation.
  (Since the "namespace bid = boost::io::detail;" ought to be somewhere in
the beginning of the file or the beginning of the function where it's used,
it ought to be hard to miss, so it's easy for the reader to know what it
means.)

  2) It greatly lessens the possibility of name collisions if some name
happened to also exist in the global namespace, or if you are doing a
"using namespace" to two different namespaces which have the same name
in them, a name you are using.

> The disadvantages are obvious - having to type bid:: before every type
> (annoying if almost every line contains several types from that namespace)

  Do you also use single-character and two-character names for all your
variables, functions and types so that you have less to type?

  Brevity only leads to obfuscation, ie. it causes the code to be harder
to understand. Using unambiguous names and prefixes makes the code easier
to read and understand.

> and your code looks very "unoptimised" when the same string is repeated a 
> huge number of times.

  Unoptimised? I don't understand what you mean. Unoptimized in what way?
At least not in execution speed or memory usage.

  Does a piece of code "look very unoptimized" if it has a lot of 'void'
and 'int' keywords? In a typical program there are usually hundreds of
them. So what?

  What does "looks very unoptimised" even mean? I don't really get it.

  You seem to be of the camp who prefers to trade clarity for brevity.
The shorter the code, the better, even if shortening happens at the expense
of clarity and readability. Well, the only thing I can say to that is that
I wholeheartedly disagree: Brevity is not any kind of virtue in programming.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   (Since the "namespace bid = boost::io::detail;" ought to be somewhere in
> the beginning of the file or the beginning of the function where it's used,
> it ought to be hard to miss, so it's easy for the reader to know what it
> means.)

I think as long as it's repeated in each source file, that's probably 
useful. If it's buried three #include files deep somewhere in a source file 
with 20+ include files to start with, it might be a little harder to find.

Especially if you write something like

namespace
bid
= boost::io::detail;

(Don't laugh. I've seen this done on the grounds that the definition of an 
identifier always starts at the left edge.)

>> The disadvantages are obvious - having to type bid:: before every type
>> (annoying if almost every line contains several types from that namespace)
> 
>   Do you also use single-character and two-character names for all your
> variables, functions and types so that you have less to type?

I always found the "::" part visually disruptive. It's a shame languages are 
still written to use only ASCII.  I guess with syntax coloring, it's a lot 
easier to skip over the syntactic noise as well.

>   Brevity only leads to obfuscation, ie. it causes the code to be harder
> to understand. 

I'll agree to this. It only helps the author, not the reader, and not even 
the author being the reader six months later.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   (Since the "namespace bid = boost::io::detail;" ought to be somewhere in
> > the beginning of the file or the beginning of the function where it's used,
> > it ought to be hard to miss, so it's easy for the reader to know what it
> > means.)

> I think as long as it's repeated in each source file, that's probably 
> useful. If it's buried three #include files deep somewhere in a source file 
> with 20+ include files to start with, it might be a little harder to find.

  Many C++ style guides have a hard rule of "no 'using' in header files,
period". (Personally I expand it to "no 'using' *anywhere*, period",
although there are situations where it might be acceptable.)

  While most of these style guides probably forget to impose rules on
namespace aliases, by correlation one can also say "no namespace aliases
in header files either".

> I always found the "::" part visually disruptive.

  I don't know about that. To me it actually makes it clearer than if there
was only alphanumerical characters, or even underscores, in the names. It
gives a quick clue that something from a namespace (or a class) is being
used here, so it helps understanding the code.

  The cretor(s) of C++ decided on "::" (an idea which might have been copied
from some other language, although I don't know which one). I'd say it's as
good of a choice as anything else. Or do you have any better suggestion?

  Once you have written a lot of code with fully qualified names, it becomes
natural and fluent (to both write and read).

> It's a shame languages are 
> still written to use only ASCII.  I guess with syntax coloring, it's a lot 
> easier to skip over the syntactic noise as well.

  Actually the C++ standard allows identifier names to be written using
UTF-8 (but I don't know how many compilers actually support this). Of
course that doesn't change any of the operators and delimiters, though.

> >   Brevity only leads to obfuscation, ie. it causes the code to be harder
> > to understand. 

> I'll agree to this. It only helps the author, not the reader, and not even 
> the author being the reader six months later.

  The latter is one of the major reasons why I have also started using
clearer variable name prefixes to distinguish between member, function-scope,
file-scope and extern variables, as well as compile-time constants. I had
a natural (and irrational) aversion towards such prefixes for years, but
once I started using them, they are actually wonderful.

-- 
                                                          - Warp

Post a reply to this message

>  (Since the "namespace bid = boost::io::detail;" ought to be somewhere in
> the beginning of the file or the beginning of the function where it's 
> used,
> it ought to be hard to miss, so it's easy for the reader to know what it
> means.)

Depends how many namespace typedefs you're using, it could easily become 
awkward to remember or check every one in a file.  Modern IDEs show the full 
type definition just by hovering over the code (which you can use if you are 
unsure about anything), so personally I have never found this an issue.

>  2) It greatly lessens the possibility of name collisions

Sure, agreed.

>> The disadvantages are obvious - having to type bid:: before every type
>> (annoying if almost every line contains several types from that 
>> namespace)
>
>  Do you also use single-character and two-character names for all your
> variables, functions and types so that you have less to type?

Not 1 or 2 characters, but I try to keep them relatively short (eg 
frWheelLoc rather than frontRightWheelLocation), otherwise lines end up 
being 80+ characters long rather than ~40, which makes a lot of difference 
to readability IMO.

>  Brevity only leads to obfuscation, ie. it causes the code to be harder
> to understand. Using unambiguous names and prefixes makes the code easier
> to read and understand.

I agree up to a point, but IME you can go too far the other way where almost 
every statement is going over several lines, you end up having to split 
would-be single statements into multiple ones, and thus functions take up 
much more lines.  Whilst it may read very nicely if you have the time, 
personally I find it slower to visually find stuff when all the variable and 
function names are too long.

>> and your code looks very "unoptimised" when the same string is repeated a
>> huge number of times.
>
>  Unoptimised? I don't understand what you mean. Unoptimized in what way?

As in it looks like you could be writing it more efficiently.  Same way as 
when you see:

myList.Add( 5 );
myList.Add( 6 );
myList.Add( 7 );
myList.Add( 8 );

You think there must be a better way to do it (using a loop).  If I see:

mfxg::CreateTexture( mfxg::Pixel( mfxg::Color(1,1,0.5) ) , 
mfxg::Style::None );

I think there must be a more efficient way to code that.

Post a reply to this message

Warp wrote:
>   Many C++ style guides have a hard rule of "no 'using' in header files,
> period". (Personally I expand it to "no 'using' *anywhere*, period",
> although there are situations where it might be acceptable.)

I heartily agree. ;-)

Altho a "using namespace" inside an individual function might make sense, or 
inside an individual class declaration, especially if it's a custom 
namespace with hard-to-confuse names anyway.

>> I always found the "::" part visually disruptive.
> 
>   I don't know about that. To me it actually makes it clearer than if there
> was only alphanumerical characters, or even underscores, in the names.

I just think "::" is too much punctuation, compared to "." or "/" or even 
just one ":" or something. It's a minor thing, really.

>   The cretor(s) of C++ decided on "::" (an idea which might have been copied
> from some other language, although I don't know which one). I'd say it's as
> good of a choice as anything else. Or do you have any better suggestion?

Everyone else (C#, Java, Python, etc) seem to get along just fine using "." 
for namespaces, member invocations, etc. I think C++ went with "::" to stay 
syntactically compatible with C.

>   Once you have written a lot of code with fully qualified names, it becomes
> natural and fluent (to both write and read).

Sure. As I say, I personally find it a bit ugly, but with syntax coloring 
it's less so.

>> It's a shame languages are 
>> still written to use only ASCII.  I guess with syntax coloring, it's a lot 
>> easier to skip over the syntactic noise as well.
> 
>   Actually the C++ standard allows identifier names to be written using
> UTF-8 (but I don't know how many compilers actually support this). Of
> course that doesn't change any of the operators and delimiters, though.

I didn't mean "ASCII" as much as I meant "plain unformatted text".  I.e., to 
build into the language something more along the lines of what syntax 
coloring gives you in IDEs.

> a natural (and irrational) aversion towards such prefixes for years, but
> once I started using them, they are actually wonderful.

I find it's rather a hinderance if you haven't really nailed down how you 
want the code to work before writing it, unless you have an IDE that lets 
you change it.  I'd also rather have syntax coloring doing this sort of 
thing, so my member variables are orange, my statics are blueish, etc.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Warp wrote:

>   Brevity only leads to obfuscation, ie. it causes the code to be harder
> to understand. Using unambiguous names and prefixes makes the code easier
> to read and understand.

Now who was it that once said comprehension = 1 / 2^precision ? ;-)

I tend to think of, say,

   sqrt(x^2 + y^2 + z^2)

as being far easier to read than the strictly more precise equivilent

   sqrt(sum(sum(power(x, 2), power(y, 2)), power(z, 2)))

(Hell, I'm now even sure I got all the brackets right!) This tells you 
in exactly which order the sum operations happen in [which shouldn't 
matter in an associative algebra, but strictly floating-point arithmetic 
isn't associative].

The first version is much more terse, yet far more understandable. In 
general, I would suggest that there's no "simple" correlation between 
terseness/verbosity and comprehensibility.

It still makes me chuckle that Java has java.lang (what, you couldn't 
spare 5 extra characters?) and System.err (what, no 2 extra 
characters?), but also has

   java.lang.ArrayIndexOutOfBoundsException

Go count how many characters that is. (BoundsException would be just as 
good...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
>   1) It makes it clear where the names are coming from (which is especially
> important if you are using names from several different namespaces, as eg.

Actually, here's another great example.

I'm trying to figure out how to use a library based on sample code that 
calls it. Both library and sample code suck (can you say 800-line macros? An 
entire multimedia jukebox written in one 14000-line main()?)

But at least if the library names were in a namespace, I could distinguish 
while I'm reading whether "audio_info" and "instance_modifier" and crap like 
that was part of the library or part of the sample program, and drill down 
until I found the actual types used by the library.

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message