 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> 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)))
That's because operators are part of the language definition itself,
which every programmer of that language should know by heart. It's no
different than 'for', 'if' and 'int' being short. As they are reserved
keywords (and there's only a relatively limited amount of them), every
programmer who knows the language knows what they mean. Likewise with
the built-in operators.
However. when you write a program and create your *own* unique types,
variables and function names, it's something nobody else has ever seen
before. It's something completely new to them. Thus the situation changes
completely: Now brevity becomes obfuscation, as the reader is seeing
something he has never seen before (because it has been created by you),
and has to figure out what it means.
Thus naming conventions and things like clear library scopes help
understanding such a program much better, even if such conventions and
scopes mean that the names become a bit longer.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> That's because operators are part of the language definition itself,
> which every programmer of that language should know by heart.
> However. when you write a program and create your *own* unique types,
> variables and function names, it's something nobody else has ever seen
> before. It's something completely new to them. Thus the situation changes
> completely: Now brevity becomes obfuscation.
My point is that sometimes having shorter names reveals the structure of
what you're trying to do more clearly. (This is why mathematicians use a
bazillion weird symbols for communication.)
But sure, I take your point that in the usual case, you want names that
are going to make sense to people and be reasonably descripting without
being too huge...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> (This is why mathematicians use a
> bazillion weird symbols for communication.)
Which works only when the symbols are well-established and known, not
unlike the keywords of a programming language.
Try understanding mathematical formulas without knowing what the symbols
mean of where they might be defined...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> (This is why mathematicians use a
>> bazillion weird symbols for communication.)
>
> Which works only when the symbols are well-established and known, not
> unlike the keywords of a programming language.
I especially love the way mathematicians have developed seperate
unrelated symbolisms for the same concepts. Or how occasionally the same
symbols can mean radically different things depending on context.
(This isn't limited to symbols of course. How many meanings for the word
"normal" can you find? There's the normal distribution, normal vectors,
normed spaces...)
> Try understanding mathematical formulas without knowing what the symbols
> mean of where they might be defined...
Been there, done that. It's not like there's a book somewhere which
tells you what all this stuff means, after all. (And I was never taught
mathematics.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
