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