=============================================================================
* Forwarded by renald loignon (1:167/133.100)
* Area : DBASE (DBASE)
* From : renald loignon, 1:167/133.100 (Sunday January 19 1997 18:35)
* To   : Steve Board
* Subj : CALCULATE, naming conventions
=============================================================================
 RL>> CALCULATE [scope] MAX(fieldname) [TO memvar]
 SB> By golly, you're right. And it works great--much faster than my
 SB> use of
 SB> arrays. The other functions are useful to. They've got everything I
 SB> need but median values.
Median?  Is that the middle of the range of values that appear in a given 
field?  If so, try this:
    CALCULATE MAX(fieldname), MIN(fieldname) to __max, __min
    __median = __min + ((__max - __min) / 2)
 SB> Thanks Renald. I owe you one.
No problem.  Sharing is what these electronic conferences are all about.
=======================================
Speaking of sharing, and as long as I'm warmed up, here is a comment on the 
above lines, which may double as a possible contribution to the general field 
of xBASE programming.  I had been meaning to write this up for a couple of 
years, and it's about time I got around to it:
The use of underscores is a personally developed naming convention of mine 
for memory variables (or "memvars").  I can only vouch absolutely for the 
legality of this practice under Foxpro 2.x, and a quick glance at an old copy 
of dBASE 4 (from a customer's backup of an obsolete application) indicates it 
could not be used in that version (late flash: it also _works_ in Visual 
dBASE 5.5).  The benefits of this approach are:
 1) Prefixes such as m->memvarname (Foxpro or vDBASE) or m.memvarname 
(Foxpro) are used to force reference to a memvar when a physical field of the 
same name may exist in the currently selected area.  However, besides adding 
tediousness to program coding (and a wee bit of size to program files), there 
is some evidence (as read in a Foxpro Advisor article) that the wholesale 
addition of these prefixes slows down programs by a measurable factor.  Using 
my naming convention, the "m->" and "m." prefixes can be dropped altogether, 
while ensuring that no physical field name will EVER conflict with my 
memvars, since physical field names MUST begin with a letter.
 2) When using SCATTER MEMVAR (in Foxpro) or STORE AUTOMEM or USE AUTOMEM (in 
vDBASE 5.5), memvars are created for all fields in the currently selected 
area. This could overwrite any existing memvar of the same name, which can 
again be prevented with absolute certainty if all programmer-defined memvars 
start with an underscore.
 3) Foxpro 2.x and vDBASE 5.5 already define certain system parameters as 
memvars whose names start with an underscore, for example _PADVANCE or _WRAP. 
To avoid conflict with these, I name my local variables with two (or more; 
see below) underscores at the beginning.
 4) As an extension to the above practice, I use the following additional 
personal conventions: global memvars start with 2 underscores, whereas local 
memvars start with 3 underscores.  At the beginning of each program routine, 
I then place the following two lines:
    PRIVATE ALL EXCEPT _*
    PRIVATE ALL LIKE ___*
The first line "hides" all memvars *_except_* those whose name start with at 
least one underscore.  The second line also "hides" all memvars who names 
start with 3 underscores (which would be local variables defined by a program 
in the calling chain), leaving only the system memvars (names starting with a 
single underscore) and my own global memvars (starting with two underscores) 
visible. I then proceed to initialize my local memvars with the certainty 
that they will not conflict with any field or memvar used elsewhere in the 
application.  An extra benefit is that when, in the course of debugging or 
modifying an application, I need to add a memvar somewhere, I do not have to 
concern myself with adding it to a "" in a PRIVATE statement, 
thereby also ensuring that I could not accidentally forget to add it.  I am 
sure most experienced xBASE programmers have encountered situations where the 
omission of a variable in a PRIVATE statement caused all kinds of strange 
behavior because of conflict with an existing memvar of the same name...
Whew!  Now that I finally committed this to print, the irony is that it may 
already be obsolete due to new features of Visual Foxpro or other recent 
xBASE development environments.  if anyone know of such a fact, please let me 
know...
Still, I hope this will prove useful to some die-hard users of the classic 
Foxpro 2.x family or the current Visual DBASE.  I would appreciate any 
feedback from users of dBASE 5.0 as to its applicability there.  Finally, if 
anyone would like to repost this text elsewhere, they may do so provided they 
attribute it properly.  I will cross-post it immediately to the FidoNet 
FOXPRO Echo, for starters...
renald loignon  (Internet: rhl@cam.org)
-+- GoldED 2.50+
 + Origin: Point of View (1:167/133.100)
=============================================================================
Hello All!
renald
--- GoldED 2.50+
---------------