Erik,
My two cents' (with allowance for inflation...)
> > If you're distributing code in cyberspace it's a good
> > idea to make it error free too, E_NOTICE or otherwise.
To get the maximum help when coding, and to ensure the minimum of
confusion for your users, I recommend:
1 set the dev server's PHP error setting to catch every single
error/warning msg, and code well (?code Shell)
2 set the prod server to not report any errors except a complete
disaster to the user (?catastrophe theory)
If they are one and the same machine/server, then use 'debug' code to
reset options at the beginning of dev code (and remove it when the
routine is 'promoted' to prod).
> I got back quite a few responses on this list on the subject of having
> variables that are not defined before they are used. That's
> interesting -- it's nice to know that I can take shortcuts and conjure
> them up on the fly, but I didn't realize that it was good practice to
> declare the variable before you actually use it in a script. (I never
> studied programming in any formal sense, as anyone who has seen my
> source code can attest :).
>
> Sometimes I create variables dynamically, such that I could never
> declare/initialize them in any realistic sense -- for instance, I
might
> have a while loop that executes a number of times equal to the number
of
> rows pulled from a database query. And in this while loop, I might
> generate a new variable (assigning it a name like $variable$i, using
the
> old $i++ trick to give it a unique numeric suffix).
>
> If I use this trick, does this doom me to never having
fully-error-free
> code? Or is there something that I'm not getting here... The short of
> it is that, as a novice programmer, I'd like to make sure I'm writing
> the most legitimate code that I can. Thanks for any input on this
> thread, past or future.
In strongly typed languages, I think there are (?have been historically)
two objectives in defining variables prior to their use:
1 to set aside the storage space, and
2 to define the variable type
1 in the case of a scalar variable this seems trivial, eg
INTEGER J
Dim intJ As Integer
In the case of an array or var/set length string, then replication needs
to be added into the equation for calculating both an individual
component's address and working out how much storage to set aside, eg
INTEGER K(10)
2 Somewhat obviously a double-precision floating point number will
require more space/bytes to store its value than a simple integer.
However a common error made when programming is that you think a
variable holds data of a certain type, when in fact you earlier used it
in some other (very similar, but not quite the same) manner. eg
//don't use this code
$User = "Fred";
later on we do (say) a db call and pull out a row of personal data:
$query = "SELECT * FROM persTbl WHERE persId = '$User' ";
//I'm assuming that persId is likely some sort of personnel/membership
number
PHP is a 'little ripper' when it comes to quick and dirty usage, because
you don't have to type a declaration line before using a
variable/assigning storage (per part (1)) - PHP works it out for
you/from context, so it can 'very fast' (from a coder's point of view).
However such does leave one open to the problems described in part (2) -
which a strongly typed language would flag as an error! To this end,
some people decide to describe the usage of each variable as part of the
name. For example I was reading some Microsoft Excel macro/VBA stuff and
there's talk of intCounter and txtNameEntered - for an integer value and
the contents of a data-entry form's text box (resp).
You have gone on to describe how the PHP attitude to typing enables the
creation of dynamic variables/variable names. This is a really powerful
feature, and has an important place in certain functions. However it is
not something I would put into an intro tutorial, because with such
power comes the potential to greatly expand the size of feet before
bringing them into close proximity with one's mouth!
One of your correspondents pointed out that a really good compromise is
the associative array - the variable name (array name) stays 'constant',
but the array argument/pointer can be almost anything as a 'label'. As
another aside, it is also an 'advance' to know that the various contents
of an array in PHP do not have to be all the same datatype (as they
do/did in other languages)! Thus:
$aPersRow[ "persId" ] = 12345; //integer
$aPersRow[ "persNm" ] = "Fred"; //string
$aPersRow[ "persDoB" ] = "1970-01-01"; //date
cf INTEGER K(10) setting aside space only for a collection of integers!
One way that I have utilised this technique is to keep a set of counters
for system/logging/reporting purposes in an associative array. The array
element/label is self-documenting, and the ability to pass them all into
a reporting sub-procedure as a single parameter/array name provides an
easy cohesion/grouping!
In PHP I have found it helpful to do something similar to the M$
conventions mentioned earlier. I have set myself a set of 'naming
conventions' for PHP to help accommodate the power of dynamic typing,
whilst avoiding the potential traps. Here is a range I've grabbed from
some code I've just been working on:
$iFrequency = 123; //is an integer
$aCounter = array(
"RowsAdded" => 0, ... ); //is an assoc array (of counters,
as described earlier)
$dBirth = "1970-01-01"; //is a date
$bValidity = MySQLdbUpdate( ... ); // is a boolean (TRUE/FALSE value)
$dbConnection //is a PHP/MySQL resource
SMTP_SERVER //is a PHP constant
$ColumnsClause = "PHASE, SEARCH, URL, FREQ"; //a variable name without
a 'prefix' is a string
PHP itself shows a really good use of its variable typing facility in
the MySQL (for example) function calls return values, which either
return a boolean value to indicate failure or a resource pointer. Some
string functions are similar, eg
$bFound = $iPosition
= strpos( $Page, $target, $iOffset ); // if false strpos()
failed, if >=0 it points to first char posn
if ( FALSE === $bFound )
{
echo "Not found"; ...
}
else
{
echo "Found at Pos=$iPosition~" . "<br>" ...
}
This code uses data typing/type-specific operators to clarify whether
we're looking for a boolean result indicating failure (note the ===
operator), or zero (the target string commences at first character
position, ie ( 0 == $iPosition ) - see warnings about this potential
confusion in the manual.
It's all a lot more work/typing, but the 'proof of the pudding' comes
when someone else comes along and attempts to read your code (or even
you, some months/years later!) - can you tell the purpose and datatype
of the various variables/values in the code fragment above? (wow, talk
about leaving yourself open for a broadside...)
>From memory the people who really get into standards for writing in PHP
in a big way are the PEAR project boys. I think there's some follow-up
reading there.
Discussion/other ideas welcome!
=dn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
