Thanks for the many replies about naming conventions. So to summarize:
1. The cryptic names are not really being pushed to make things
unreadable, but as protection from the deficiencies of Rev.
2. The lack of a naming scope somewhere between local and global
(such as namespace or the method I suggested) has resulted in the
burden being passed on to the programmer to come up with a hopefully
(but not guaranteed) unique naming convention for globals that he
wants to own exclusively. Just putting a "g" in front of them is no
better than not --because if everyone puts a "g" in front they are
all in alignment again, but what the heck, I'm not going to be able
to pronounce it anyway so I'll throw it in just so someone can
understand why the name is ridiculously long. You need to come up
with something that does not look like an understandable name because
that might seem like a good name to someone else also. So if we want
to use a global, we really need to have a registry of global prefixes
so that a developer can claim a unique one. For example I might want
to use gSee3d<number><name>. The number is so I can serialize my
different projects (I will need my own private registry to keep track
of those), and the name is what I want to call my global. For
instance gSee3D005FilePathToMyData. Yes, I think I understand it now
--where is the nearest restroom?
BTW: My current project (1 stack 1 card) has over 100 globals defined
(many are large arrays) so that I can use a combination of created
scripted groups of objects and common handlers where possible without
needing to pass many arguments. I have to do this awkward thing to
make up for the slow speed of array processing and ironically to make
my scripts maintainable. Using names like these would cause my
script lines to be very long an completely unreadable! I use names
like TF1,TB1 now instead of TriggerField1 and TriggerButton1. I just
define the abbreviations in the comments of the handler. If my
shortened names were gSee3D005FTF1, gSee3D005FTB1, I might have a
hard time skimming the difference in the names causing more bugs.
I would not mind if the Rev IDE would allow me to do something like:
set privateGlobals to "See3d005". I will declare: privateGlobal
TB1,TF1, or possibly: privateGlobal "See3d005" TB1,TF1. Then
internally, the IDE can prepend the See3d005 to TB1, but in my
scripts I only have to use TB1. That should be trivial to implement
and I could happily live with that.
3. The reason for making local variables a bit ugly is to guarantee
that they will not conflict with future keywords. That is a
reasonable consideration and bears further thought on the "nicest"
way to do that. Of course explicit variables is a good idea here.
If you declare a local name, it should override when it makes sense
as a variable name so future names will not break old stuff. It is
also highly likely that a handler for a missing capability might use
the same name when a built in command is created in the future.
4. The reason for making custom property names a bit ugly is to
guarantee that they will not conflict with future built-in
properties. That is a reasonable consideration also and bears
further thought on the "nicest" way to do that.
aWell bThis cIs dVery eInterresting. fPerhaps gWe hCan iPropose
jSomething kThat lMakes mA nBit oMore pSense qBy rAddressing sThe
tReal uIssues vBetween wWhat xUsers yNeed zTo aDo, bAnd cWhat
dTranscript eNeeds fTo gDo.
I don't know about you, but my skimming speed is as slow as Rev array
processing when I try to read the last sentence (and I just wrote it)!
Did I miss any important points?
On Jun 21, 2005, at 4:58 AM, Dave Cragg wrote:
On 20 Jun 2005, at 21:06, Dennis Brown wrote:
Dar,
Thank you for standing up for the rights (in a good natured way)
of those who think it's overkill to have all these structured
names in a conversational language with handlers that are usually
only a few lines long. Why mar the elegance of a understandable
name with cryptic unpronounceable prefix letters all over the
place? It's not as if I wouldn't be able to instantly recognize
ten years later what the local variable named partNumber in my 20
line script was for, or even that it was a local.
I sympathise with your view. Although I use east-central-Hungarian-
semi-strict myself, I'd hate to see this stuff forced on anyone.
But there are advantages that it's useful to know about. Others
have mentioned namespace clashes. Another advanatge relates to your
"ten years later" comment. xTalks have a large number of reserved
words in the form of commands, functions and properties, and over
time this number has grown. So a variable with a friendly name you
create now, may become a reserved word ten years from now. Those
who spend any time converting old Hypercard stacks probably know
how frustrating this can be. As an example, I recently converted
some Hypercard stacks that used the names "startframe" and
"endframe" as parameters in various message and function handlers.
I'm sure these seemed appropriate to the original author, but the
Rev compiler didn't like them. Rather than spend time thinking of
alternative available "natural" names, I just stuck a "p" in front
-- pStartframe, pEndframe. This quickly becomes a habit, so that
in no tTime, you gFind yourself taking sThis approach to pAll
variables.
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
