Sunday, August 21. 2005
Typing PHP
One of the somewhat unique features of PHP is that it is not a strongly typed language. This means that in the event of a type mismatch, variables are automatically cast into whatever variable type (integer, string, etc.) the interpreter deems most appropriate for the operation. Which is typically fine and in fact a boon to most beginning programmers, and fine for experienced programmers that understand the rules of engagement. However, as I was explaining a concept in PHP to a beginning programmer earlier today, it dawned on me that the code he was looking for:[geshi lang=php]if (in_array($user,$users)) {
//…[/geshi]
could be improved in terms of intelligibility by being written as:
[geshi lang=php]if (in_array($user_string,$users_array)) {
//…[/geshi]
That is, by building in the intentions of the author with regard to the variable type in to the variable name, the code becomes more legible, understandable, and ultimately maintainable.
The same could be done for functions, by appending the return type to the end of the name.
[geshi lang=php]function foo_bool($bar_int, $baz_string) {
//…[/geshi]
In this way, all the basic information you need about the function (return type and variable input types) is available right in the function definition. While it certainly wouldn’t do away with the need for a good description (preferably in a PHPDoc DocBlock) it goes a long way toward explaining the code within the code using simple mnemonics.
Anyone else already using this approach?
< Previous Entry | Next Entry >
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Though I have somewhat used this in my own programming, I think you may have something there.
Very interesting.
Very interesting.
By making in_array more readable, the errors are easier to spot 
. (in_array’s params are needle, haystack, so you switched the parameters).
What you propose is similar to the ‘hungarian notation’ (http://en.wikipedia.org/wiki/Hungarian_notation) that used to be common among programmers years ago. Instead of bar_int and bar_string you would write iBar and sBar.
There are several disadvantages to this in PHP however. Although you could consider this bad coding, it is valid, and PHP will not complain about the types:
$a = 5; // $a is now integer
$a = "hello ".$a; // $a is now a string
. (in_array’s params are needle, haystack, so you switched the parameters).What you propose is similar to the ‘hungarian notation’ (http://en.wikipedia.org/wiki/Hungarian_notation) that used to be common among programmers years ago. Instead of bar_int and bar_string you would write iBar and sBar.
There are several disadvantages to this in PHP however. Although you could consider this bad coding, it is valid, and PHP will not complain about the types:
$a = 5; // $a is now integer
$a = "hello ".$a; // $a is now a string
Thanks, Ivo. I corrected this in the examples. Just another peculiarity of PHP, since most of the string functions are haystack then needle…
To respond to your concern about mutable types, I would recommend against changing types in PHP at all. That is:
$a_int = 5;
$b_string = "hello".$a;
I have seen many beginning programmers confuse themselves and others by altering the variable type in the course of their code.
To respond to your concern about mutable types, I would recommend against changing types in PHP at all. That is:
$a_int = 5;
$b_string = "hello".$a;
I have seen many beginning programmers confuse themselves and others by altering the variable type in the course of their code.
Visual Basic has a similar concept, the Variant datatype. (Note in VBA and VBScript, ALL variables are Variant types, in effect the same as PHP).
It’s a special datatype than can contain data of any type (even an object). VB naming conventions (based on hungarian) uses the prefix ‘vnt’ to indicate the variable is a variant.
So your example would become:
$vntA = 5; // $a is now integer
$vntA = "hello ".$vntA; // $a is now a string
In this way you are giving yourself a visible clue that the variable ‘can be any type - beware!’
Coming from a VB background I used to code my PHP using this format, but it just… looks… wrong :-S
It’s a special datatype than can contain data of any type (even an object). VB naming conventions (based on hungarian) uses the prefix ‘vnt’ to indicate the variable is a variant.
So your example would become:
$vntA = 5; // $a is now integer
$vntA = "hello ".$vntA; // $a is now a string
In this way you are giving yourself a visible clue that the variable ‘can be any type - beware!’
Coming from a VB background I used to code my PHP using this format, but it just… looks… wrong :-S
I’ve come across this before (even tried it out a bit), but I don’t really like it. It comes down to preference, of course. Well, that and an agreed on coding standard when working with others.
But I find the dynamic aspect of it helpful to have that flexibility. I don’t have a habit of switching types around, but I’d rather take advantage of the system rather than use it as statically typed.
By the same token, even though Objective-C has type declarations you could declare things as ‘id’ and name them foo_string. Or declare them as strings and name them foo_string as a reminder.
It seems like an idea that had a good reason for coming up, but not one that works for me.
But I find the dynamic aspect of it helpful to have that flexibility. I don’t have a habit of switching types around, but I’d rather take advantage of the system rather than use it as statically typed.
By the same token, even though Objective-C has type declarations you could declare things as ‘id’ and name them foo_string. Or declare them as strings and name them foo_string as a reminder.
It seems like an idea that had a good reason for coming up, but not one that works for me.
