0

Scenario: We are in the process of converting an application from PHP 4 to PHP 5. The application needs to be able to work on PHP 4 for a little while, which means no PHP 5 specific elements can be used, yet. We are simply trying to make sure the application works on both platforms.

There are a lot of conditionals that look like this in the application:

if ($variable) { // do something }

Some of these variables end up not being defined at all and we are trying to reduce the number of errors (there's a lot of them).

To solve these errors, we are adding checks in various areas like this:

if (!isset($variable)) $variable = "";

or

if (!empty($variable)) { // do something }

Question: Does anyone know of a simpler approach to fixing these errors. The problem is that these variables are being used across files (via includes) and defining the variable may change the logical flow in that file if its doing a check like (if (!isset($variable)) { // do something }).

The point of this question is to reduce errors and time consumption of tracking each individual use of these variables. Currently, we are having to either examine thoroughly what the variable is doing (which may take a good chunk of time), or we are doing a "fire and forget" / hope-its-fixed method of correcting.

-- Edit -- Does anyone know of a program like cppcheck for php that could somehow reference these variables or create some kind of chaining that could find errors and link possible references? (I hope that makes sense.)

hakre
  • 193,403
  • 52
  • 435
  • 836
teynon
  • 7,540
  • 10
  • 63
  • 106
  • What's wrong with using `isset` or `empty`? Just that it's a lot of work? – Explosion Pills May 24 '12 at 18:43
  • To me it sounds like a rewrite (directly into PHP5.3) would be less complicated, than the refactoring. – KingCrunch May 24 '12 at 18:43
  • @ExplosionPills - It can sometimes change the logical flow of the program. Setting a variable may break it later if there is a condition checking if it is set or not. This is a large application. – teynon May 24 '12 at 18:45
  • @KingCrunch I would prefer that, but received sad faces when suggested. – teynon May 24 '12 at 18:46
  • 1
    but undefined variables will only return a notice in PHP 5 and not a fatal error.... – Flukey May 24 '12 at 18:46
  • 2
    @Flukey: An error is an error. Whatever it is, it should be fixed. – animuson May 24 '12 at 18:47
  • I agree, however, it seems like a pointless exercise if they're spending so much time on suppressing notices when they should just rewrite it. – Flukey May 24 '12 at 18:49
  • @Flukey As animuson said, its still an error. These errors also cause information overload when debugging comes into play. – teynon May 24 '12 at 18:49
  • Notices are useful. Suppressing them with `isset()` and `@()` is the common approach, but often hinders debugigng later on. Now if you have hundreds of them, that doesn't aid it either. So what you actually need in place of the dumb defaul error handler, is an error manager, for documenting and decorating notices. Still some effort, but better than needless variable declarations. (The only point of the Zend runtime is to allow execution with absent zvals. If you refuse to utilize that, you're using the wrong language type.) – mario May 24 '12 at 19:05

1 Answers1

0

AFAIK there is a code-checker that looks for uninitialized variables which works OK. You can work through it's messages, it's called PHP Mess Detector and one of it's rule covers uninitialized variables. However this can never be perfect.

Another method is to track the error messages and use them to locate the places within in the code. I've done that in the past and it worked very well, just do it in iterations and keep log of the warnings.

You can also work with a whitelist and import whitelisted variables when the request starts. Non-whitelisted submissions need to cause an access violation error to have this properly working, so this way is more work than tracking warnings albeit it might make your application more secure.

Please see as well:

Community
  • 1
  • 1
hakre
  • 193,403
  • 52
  • 435
  • 836