John VanSickle wrote:
> 
> As you may have learned by now, if you re-use a variable name in your
> POV-Ray scripts, and then use that variable later, you have to make it
> the same type of thing both times, or POV-Ray will bomb out with an
> error.
> 
> For instance,
> 
>   #declare J=0;
> 
> // other stuff
> 
>   #declare J=<2,3,1>;
> 
> will result in the error message "Attempted to redefine float
> identifier as vector identifier."
> 
> I have found that adding a single character to the front of the
> variable name is of great help in avoiding this problem.  It prevents
> the example problem by forcing the two different values to be placed
> into different variables altogether.  Assuming that the first J is
> supposed to be a scalar, and the second a vector, the two declares
> would be written this way:
> 
> #declare sJ = 0;
> 
> #declare vJ=<2,3,1>;
> 
> Not only does this prevent the aforementioned error from bringing your
> parsing to a grinding halt, it also helps you remember what a
> particular
> variable is supposed to be doing.
> 
> This is especially helpful if you are working on a group project and
> need to understand the other people's scripts, and avoid clobbering
> the variables they're using.
> 
> This convention rests on adding a lower-case letter to the start of
> all
> variable names, except for objects, and for including at least one
> upper-case letter after this point, to avoid conflicts with the
> reserved
> words in the POV-Ray scripting language.
> 
> Anyway, here are the letters I'm using, and what they stand for:
> 
> c = the total number of a group of objects (ie, count)
> f = a scalar representing a flag
> i = an index
> l = a scalar representing length
> p = a vector representing a specific point in space
> r = a scalar representing the radius of something
> s = a scalar
> v = a vector
> 
> I don't use this method for naming pigments, textures, or materials,
> but I haven't had the name-collision problems with those.
> 
> Hope this is found to be of use,
> John
> --
> ICQ: 46085459

Very useful suggestion.
Funny thing is, I knew this one, I believe it's a rather well known
programming technique but it never occurred to me to actually use it (as
with a lot of other things that would really help me get my work
structured). 
I'm not sure if I understand your choice of letters or categories but I
think I'll try it out some time. I often have conflicts of this type,
especially with scenes that use a lot of independantly created inc-files
(that use #declare where they should use #locals - another habit I
should do something about....)

If it's just to avoid conflicts it might be enough to distinguish the
different type of vectors. Perhaps a pv (point-vector), cv
(colour-vector), tv (transmit-colour-vector), fv (guess...)
It might also be useful to distinguish reals from integers (or variables
that are supposed to be), for counters for instance. 
How about #macros and objects?
Hm, this might get somewhat complicated....

Remco

Post a reply to this message