Feb 05 2007
In Essential PHP Security (p. 16), Chris Shiflett writes “A variable is just a container for … data, and it can always be overwritten later in the script with tainted data. Of course, this is why [it] is called a variable. If you don’t want the data to change, use a constant instead.”
I guess I thought a variable earned its name more from its variability than its changeability, but on the conclusion, Chris and I agree: any value that has no reason to change over the course of a program’s execution ought to be declared as constant.
It might seem pointlessly thorough to declare a variable as constant when it is known by the programmer to be utilized only in a read-only fashion, but if multiple programmers are working as a team, or if code will one day be maintained by a different engineer (which is likely), the only way to make reasonably sure someone won’t accidentally reuse a sensitive variable is for someone to make a list of variables already in use. And if you’re going to be making a list, you might as well make it a list of constants and include it in the code, which offers the added advantage of actually preventing accidental reuse, not just creating documentation nobody has time to read anyway.
Most people who have worked with a substantial amount of team code can probably identify with the frustration of adding some code that mysteriously breaks the application in a way that’s completely unrelated to the change, only to find out it was a variable used twice. I wouldn’t say this is an every day kind of problem (or I wouldn’t be mentioning it), but it is a high risk problem: if someone you trusted told you that somewhere in your code was a supposedly single-use variable being used twice, would you try to find it and fix it? Of course, because it would represent an unknown with a potentially dangerous downside.
Another benefit: it makes you think about what you’re going to be doing with a variable.
Finally, if you’re still unconvinced, check out PHP Language Reference : Chapter 13. Constants. It’s easy!
Related posts:
Posted by Benjamin Field on Monday, February 5th, 2007, at 6:00 am, and filed under Articles.
Follow any responses to this entry with the RSS 2.0 feed.
You can post a comment, or trackback from your site.
Larry J. Hughes, Jr. | 09-Feb-07 at 1:52 pm | Permalink
Hmm, I don’t like this argument at all. I’ll use the generic word “container” for simplicity.
* There’s a big difference between a container varying over the execution of a
program and varying over the life of a program. The simplest case is when a container derives from a command-line argument which changes periodically. I’m sure you get that, so it’s possible your semantics were just a little off.
* There are constants and there are constants. A good one is the number of seconds in a day. A bad one is the number of buildings your company occupies. A frightening one is the number of digits required to represent a year. It’s a judgement call, and if you’ve read much of other people’s code…well, ’nuff said..
* Many containers are best passed as arguments. This promotes modular and reusable code, lest you end up having to recompile and relink all modules in a ginormous project — say, an OS kernel — vs. just one. That’s why unix ‘make’ exists.
* Try debugging a program that was erroneously linked with object code that was previously compiled with a different constant [sic] value!
* The choice isn’t always binary - static variables for example.
This is just a partial list. I’m not saying you don’t want to use constants, but I am saying they must be used very judiciously!
Truth in advertising: I haven’t read any of that book.
Benjamin Field | 15-Feb-07 at 5:16 pm | Permalink
Thanks for your comment, Larry. I think these are good principals to be reminded of concerning constants, and I appreciated the balance that I gained in my perspective by considering your points.
I would add only that, at least at my house, I’ve seen the number of seconds, which typically remains fairly constant, increase dangerously on the fourth Thursday in November around about when the pumpkin pie comes out.
In an interpreted web application language such as PHP, where changing the configuration often means changing code, where copying and pasting is more common than linking and compiling, where code is promiscuous, and runtime arguments come from an untrusted user running code on your box, it’s possible to be more liberal with the use of constants and save – not create – headache.