Edouard <pov### [at] edouardinfo> wrote:
> I've seen quite a lot of code in my time that looks like this:

> std::vector< std::string > v1 = someFunction();
> std::vector< std::string > v2;
> std::transform( v1.begin(), v1.end, v2.begin(), std::bind1st( std::not_equal_to<
> std::string >( "" ) ) );
> for( std::vector< std::string >::iterator i = v2.begin(); i != v2.end(); ++i )
>     std::cout << *i << std::endl;

> and I have trouble with it in terms of readability.

  Well, I can honestly say that I don't. To me it's perfectly readable, and
the 'std::' prefixes make it even clearer what is a standard type or function
and what is a local variable, hence making it *more* readable to me than if
the prefixes had been omitted.

> There are namespace
> qualifiers everywhere, and they don't convey any useful information to me. If I
> see a "vector< string >" in some code, I make the assumption that it's a
> std::vector and a std::string.

  Well, that's the problem: Without the prefixes you have to make an
assumption. With the prefixes you don't have to assume anything.

  If your programming policy is to skip the namespace prefixes, then you also
have to use additional extraneous coding conventions in order to avoid name
collisions with the standard library. For example, you must never use a
function name or type which might be the same as one existing in the standard
library. Given how extensive the standard library is, it's not completely
unlikely that naming collisions won't happen.

  What is worse, even if your code doesn't clash with the standard libraries
*now*, they might start clashing in the future when new names are introduced
to it.

  However, if you always fully qualify names in the std namespace and never
use 'using namespace std' then you don't need those extra coding conventions
because it's much less likely for name collisions to happen, now or in the
future.

  Thus fully std:: qualifications are not pointless. Not only do they
increase readability (yes, I stress that point a lot), but they also make
the code more robust and less likely to break in the future.

-- 
                                                          - Warp

Post a reply to this message