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

Post a reply to this message

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

This is something that I had not considered. It seems to be a good idea.
I will be trying it in the future.

John VanSickle wrote:
>
> 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
>
> Hope this is found to be of use,
> John
> --
> ICQ: 46085459

-- 
Mr. Art

"Often the appearance of reality is more important 
than the reality of the appearance."
Bill DeWitt 2000

Post a reply to this message

John VanSickle <van### [at] erolscom> wrote:
: s = a scalar

  What would be the letter to put in the name of a string identifier?-)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Remco de Korte wrote:
> 
> John VanSickle wrote:
> >
> > 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'm not sure if I understand your choice of letters or categories but
> I think I'll try it out some time.

Well, they're based on English words; your mileage may vary.

> 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.

Cardinal numbers (ie representing the total number of a kind of item) have c at the
beginning. 
Ordinal numbers (representing which item in an array, perhaps) begin with i.

Reals that represent a length begin with l (the letter).
Reals that represent a radius begin with r.
Other reals start with s (for scalar).

> How about #macros and objects?

I haven't had more than one or two collison problems with those.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

Nieminen Juha wrote:
> 
> John VanSickle <van### [at] erolscom> wrote:
> : s = a scalar
> 
>   What would be the letter to put in the name of a string
> identifier?-)

I don't use them very often, so I've never had to use one.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

John VanSickle wrote:
> 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.

Good idea. I've been using a variation on it for a few months now.
Of course, I extended it to everything I could think of that could
be #declared. (And then lost the file I kept it in to a backup
error and had to rebuild it so it probably isn't complete anymore),
but I have found it useful indeed and have been trying lately to 
force myself to remember. The rules I use are 2-4 letter prefix, 
followed by a mnemonically helpful name. Prefix in lower case, each 
word of name capitalized. You're right, it is quite helpful in 
preventing name clashes and identifying variable types. Not 100% 
effective in the name clash thing, but usually you can get around 
the problems that still exist by suffixing the variable name with 
a letter or digit to distinquish different "components" of the same
object. 

I never thought of distinguishing between floats and, for example,
integer looping variables, or booleans, or different kinds of 
vectors (all floats are "fv-" and all vectors are "vec-" in my 
code) but considering half the point is to identify the use of the
variable, that's not a bad idea, really.

Post a reply to this message

I like your tip.  But I usually make up long key_words discribeing the
variable.

Ambis

"John VanSickle"  wrote in message:
> 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

Post a reply to this message

I try to use the following rules, although my syntax isn't always
consistent:
* always begin with an uppercase to prevent collision with future / patch
names (I do not like this one, but it is useful)
* for inc files, begin with a 2-4 acronym for the file name (I usually do
not do this while developing the file, but add this with some "replace all"
operation when I start including it in other files)
* use descriptive names, like "JoiningSphereRadius"
* use a type description suffix like "_pi" for pigment

On the whole this gives quite long names. One (boggus) example:
"TormInnerTorus_tx" (Torus Madness, Inner Torus, texture)


 This make reading formulas difficult. So, I use two solutions:
* use work names during development, and replace them when finished
* use #local cryptic names with only the file acronym, often doing things
like
      #ifndef( TormTotalTorusCount_int) #declare TormTotalTorusCount_int=15;
#end
      #local TormIt1= TormTotalTorusCount_int;
      or
      // Total number of torii parts
      #local TormIt2=
TormTotalTorusCount_int*TormTorusDecompositionSteps_int


Philippe

Post a reply to this message

On Tue, 1 Feb 2000 12:25:27 +0100, Philippe Debar wrote:
>* always begin with an uppercase to prevent collision with future / patch
>names (I do not like this one, but it is useful)

You don't have to begin with an uppercase letter, as long as you use one
somewhere in the name.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message