No E_NOTICE for undefined variables in array? - php

So.. I'm still confused by this, when creating an array with $array = array(); and then manually setting variables like:
<?php
$array[] = 1;
$array['type'] = 2;
$array['number'] = 3;
I know, this is OK for PHP to do, but then when I echo something like $array['none'] it won't show a E_NOTICE for undefined variables.
Can someone explain me, why?

It will. If you have turned on error reporting, it should display a warning similar to the one below:
Notice: Undefined index: none in /path/to/script.php line X.
To check, try the following:
<?php
ini_set('display_errors',1);
error_reporting(E_ALL);
$array = array();
echo $array['none'];
And, if you want to actually make sure they exist before trying to use them in your code, use isset():
if(isset($array['none'])) {
// do stuff ...
}
See it live!

All this is explained on the config doc page, too:
Enabling E_NOTICE during development has some benefits.
For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging.
NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.
It's quite simple: When you access a key that doesn't exist, and assign it a new value, PHP will create that key, and add it to the list (or array). But when you try to access a non-existing key, and attempt to echo it's value, PHP won't crash, but it'll let you know that your code contains a possible bug:
$arr = array('foo' => 'bar');
echo $arr['fo'];
This issues a notice because my code may contain a typo. I may expect the key fo to exist, while clearly it doesn't, so I need to work on my code some more.
Another reason why this notice is issued is because lookups for non existing properties/keys are "slow". In order for PHP to know for a fact that the key doesn't exist, the entire array has to be scanned. That, too, is not ideal, though inevitable at times. If you have code that issues tons of E_NOTICE's, chances are that some simple if's, like:
if (!isset($arr['fo']))
{
$arr['fo'] = '';
}
echo $arr['fo'];
Will, though adding more code, effectively speed up your code. Not in the least because issueing notices isn't free (it's not that expensive, but not free either).
Other benefits:
Notices also let you know when you forgot to quote array keys, for example
echo $arr[foo];
echo $arr['foo'];
Initially, both will echo bar, but let's add 1 line of code to this:
define('foo', 'bar');
echo $arr[foo];
echo $arr['foo'];
This won't, because foo is now a constant, so $arr[foo] amounts to $arr['bar'];, which is an undefined index. Turning off notices, will just echo the string representation of NULL, which is an empty string.
Basically, notices help you. Use them, listen to them, and fix them. If your site is broken, fix it. If you get into the habbit of ignoring these notices, you'll probably set your ini files to a more "forgiving" setting, and grow lazy.
As time progresses, your code will become ever more messy/smelly, until such time you actually have a difficult to trace bug. You'll decide to turn your error reporting to E_STRICT | E_ALL, and won't be able to see the actual notice/warning that points out where your bug actually is, because your screen will be cluttered with E_NOTICE undefined index/variable...

Related

PHP "Notice: Undefined index" is it harmless or a real error?

While my site was working without any problem I suddenly started to have a really high CPU usage on my server so I started to check the code more carefully and enabled E_ALL error reporting.
Then I found out I had a great many of this "notices":
Notice: Undefined index: userID in /var/www/vhosts/mydomain.com/httpdocs/header.php on line 8
Most or them refer to unset cookies, for example this:
$uid = $_COOKIE['userID'];
If the user is unlogged I get a notice right there, and every time I use $uid.
What I want to know if this: Are this notices harmless or can they really cause any problems in my site? (Speed issues, errors etc.)
It is a notice only, try this code:
$uid = isset($_COOKIE['userID']) ? $_COOKIE['userID'] : 0;
It is not hamless (depending on the point of view), and you can disable this with error reporting functions, otherwise, the correct way is verify if index exists isset($_COOKIE['userID']) and if not, define a default value (null for instance)
$var = isset($foo) ? $foo : 'default';
You need to verify if variable exists, if you don't known it exists or not.
$var = 'foo'
if($var == 'foo') { // I known $var is defined, because I have defined it.
[..]
}
/**
* Above, I don't known if user go to mywebsite.com/index.php or
* mywebsite.com/index.php?foo=bar, so, I need to verify if index is defined
*/
if(isset($_GET['foo']) && $_GET['foo'] == 'bar') {
[...]
}
Those notices will cause a little bit of a speed problem, because raising a notice costs some extra effort.
The main problem though is that this is a serious error. You are trying to work with something that doesn't exist. This may or may not lead to Bad Things Happening, but it means your program is not correct. Since you should always develop with error reporting on full power to see and solve actual problems, notices about undefined indexes or undefined variables are serious and need to be solved. Anything that PHP complains about is serious and needs to be solved. See The Definitive Guide To PHP's isset And empty.
Notices are in general harmless, yet they may indicate a poor application design. In general it is always a good idea to utilize available PHP tools (i.e isset($someVar)) to make sure that your business logic is taking proper care of variable initialization. When you see no such notices with E_ALL error reporting setting, it's always better.
The Notice warning is in the first point of view harmless, but you should keep in mind, that the programming is not right and it might be causes errors on following lines.
In your example it es better to use
$uid = isset($_COOKIE['userID'])?$_COOKIE['userID']:0;
So you can be sure, that $uid always has a value and when the value greater then 0 you have a falid userId ...

Defining constants with $GLOBALS

I want to use a global variable setup where they are all declared, initialized and use friendly syntax in PHP so I came up with this idea:
<?
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);
$GLOBALS['debugger'] = 1; // set $GLOBALS['debugger'] to 1
DEFINE('DEBUGGER','$GLOBALS["debugger"]'); // friendly access to it globally
echo "1:" . DEBUGGER . ":<br>";
echo "2:" . ${DEBUGGER}. ":<br>";
echo "3:" . $GLOBALS['debugger'] . ":<br>";
if (DEBUGGER==1) {echo "DEBUG SET";}
?>
generates the following:
1:$GLOBALS["debugger"]:
Notice: Undefined variable: $GLOBALS["debugger"] in /home/tra50118/public_html/php/test.php on line 8
2::
3:1:
How can there be an error with 2: when clearly $GLOBALS["debugger"] IS defined? And then not generate a similar notice with the test at line 10?
I think what I am trying to do is to force PHP to interpret a string ($GLOBALS["debugger"]) as a variable at run time i.e. a constant variable variable
Disclaimer: I agree with the comments, globals are generally a bad idea.
That said, there's a few questions here that are worth answering, and the concept of indirection is useful, so here goes.
${'$GLOBALS["debugger"]'} is undefined. You don't include the leading '$' when using indirection. So, the correct version would be define('DEBUGGER', 'GLOBALS["debugger"]').
But, this doesn't work either. You can only access one level down via indirection. So you can access the array $GLOBALS, but you can't access keys in that array. Hence, you might use :
define('DEBUGGER', 'debugger');
${DEBUGGER};
This isn't useful, practically. You may as well just use $debugger directly, as it's been defined as a global and will be available everywhere. You may need to define global $debugger; at the start of functions however.
The reason your if statement is not causing notices is because you defined DEBUGGER to be a string. Since you aren't trying to use indirection in that line at all, it ends up reading as:
if ("$GLOBALS['debugger']"==1) {echo "DEBUG SET";}
This is clearly never true, though it is entirely valid PHP code.
I think you may have your constants crossed a bit.
DEFINE('DEBUGGER','$GLOBALS["debugger"]'); sets the constant DEBUGGER to the string $GLOBALS["debugger"].
Note that this is neither the value nor the reference, just a string.
Which causes these results:
1: Output the string $GLOBALS["debugger"]
2: Output the value of the variable named $GLOBALS["debugger"]. Note that this is the variable named "$GLOBALS["debugger"]", not the value of the key "debugger" in the array $GLOBALS. Thus a warning occurs, since that variable is undefined.
3: Output the actual value of $GLOBALS["debugger"]
Hopefully that all makes sense.
OK, thanks to all who answered. I think I get it now, I am new to PHP having come form a C++ background and was treating the define like the C++ #define and assuming it just did a string replace in the precompile/run phase.
In precis, I just wanted to use something like
DEBUGGER = 1;
instead of
$GLOBALS['debugger'] = 1;
for a whole lot of legitimate reasons; not the least of which is preventing simple typos stuffing you up. Alas, it appears this is not doable in PHP.
Thanks for the help, appreciated.
You can not use "variable variables" with any of the superglobal arrays, of which $GLOBALS is one, if you intend to do so inside an array or method. To get the behavior you would have to use $$, but this will not work as I mentioned.
Constants in php are already global, so I don't know what this would buy you from your example, or what you are going for.
Your last comparison "works" because you are setting the constant to a string, and it is possible with PHP's typecasting to compare a string to an integer. Of course it evaluates to false, which might be surprising to you, since you expected it to actually work.

Is it alright to suppress/hide PHP notices?

I've suppressed notices for quite some time with no problems whatsoever but I am beginning to wonder if I'm doing the right thing. I can't seem to find any logical reason why I shouldn't just suppress them but some other people seem to think that suppressing them using error_reporting is a horrible thing to do, but why?
The closest thing to an answer I could find was in this question but that's still far from the answer I'm looking for. Is there some sort of unforeseen downside to hiding all the notices that PHP generates? For example, to include a variable from a POST call back into the form because there were errors, I would simply use:
<?= $_POST['variable'] ?>
This would generate a PHP notice. To fix that notice, I could use something like this:
<?= isset($_POST['variable']) ? $_POST['variable'] : '' ?>
But, is this really necessary? Will my code actually benefit any from doing this rather than just echoing the variable whether it exists or not and potentially creating a PHP notice? It seems to me that being able to ignore notices is a benefit of using PHP as then you don't have to worry about whether a variable is defined or not, especially for an example such as this where it doesn't seem to matter.
I also take advantage of PHP's ability to automatically change a variable's type/casting depending on how it's being used and you will often find code snippets such as this:
for ($i = 0; $i < $limit; $i++) $results[] = $i; // Example
where $results has not been previously defined, but is turned into an array when I try to add a new item to it as an array. I sort of prefer doing it this way because if no results are added to the array and I need to store that information or convert it to JSON for whatever reason, then that particular variable will not be defined and thus save additional bandwidth, even if it's minute.
$data = stdClass; // For reference, in my case this would be defined before this code
$data->results = array();
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// {"results":[]}
versus
$data = stdClass; // For reference
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// []
The question again: what real benefit, if any, do I gain from fixing notice errors rather than just suppressing them? How can/would it harm my code?
In my point of view, you should never suppress errors, any kind of them, notices or not. It might give you some convenience right now, but down the road, you'll face many, many problems with your code when you are maintaining it.
Suppose you have a variable you want to echo out like the above first example. Yes, using isset is a little complicated, but maybe your application should handle the special empty case anyway, thus improving the experience. Example:
if (isset($var)) {
echo $var;
} else {
echo "Nothing is found. Try again later.";
}
If you only had echo $var; and if this was a public facing view a user was reading, they would just see nothing there, which may cause confusion. Of course, this is just one special case where fixing PHP Notices can improve your application.
It shouldn't be taken as a trouble or inconvenience when you are taking care of notices in PHP code, because code is supposed to be clean. I'd rather have a notice-free code than seeing clean code when I open it in source. Of course, both is definitely better! :)
Again, the errors (even if they aren't fatal) will cause problems down the road. If you're already doing things like echo $var; without checking it, that's an assumption that a variable exists, even if you know it might not, it will just give you a habit of assuming things exist and work. This might be small right now, but after a while you'll find out that you'll cause yourself many, many problems.
The notices are there for a reason. If we all did error_reporting(E_ALL ^ E_NOTICE) in our code, we're just being irresponsible for our code. If you are able to fix it, then why are you being lazy and not doing so? Sure, ship 1.0 with notices, fix them later, that's what we all say. But it is better to do that as a habit, code perfect the first time. If you spend 15 minutes writing code plagued by notices, and then spend 2 hours in later development time fixing them, why not just spend an hour and a half perfecting the code as you write it in the first place?
Writing good code should be a habit, not an inconvenience.
Error messages are there for a reason. Respect them, fix them, and there you go, you're a responsible programmer.
You also pave a path for the future maintainers of your code.
Suppose that you have a notice that you shouldn't ignore.
This notice will be hidden into all notices that you usually ignore.
IMHO, warnings should not be ignored. You should always take care of warnings to prevent bug. Every time I have a notice in my log file, I treat it like a bug.
Also, if your site is accessed by a lot of user, you'll get a very big log file.
In my experience, notices usually indicate a good chance that there's a bug somewhere in your code, usually of the case where you expect a certain variable to be set at a certain point but there will be cases where it isn't, and you'll start wondering why some part of your page isn't showing up or starts crashing randomly.
Of course computers aren't all that smart, and there will be cases where the code is clear enough and you don't care if there are any warnings, but that's what the # operator is for.
I respectfully disagree with some of the comments that suggest that you should never suppress notices. If you know what you are doing, I do think using # is very useful, especially for handling unset variables or array elements. Don't get me wrong: I agree that in the hands of an inexperienced or sloppy programmer, # can be evil. However, consider this example:
public function foo ($array) {
if (isset ($array[0])) {
$bar = $array[0];
} else {
$bar = null;
}
// do something with $bar
}
is functionally identical to
public function foo ($array) {
$bar = #$array[0];
// do something with $bar
}
but is IMHO less readable and more work to type. In these types of cases, I know there are exactly two possibilities: a variable is set or it isn't. I don't know in advance, but I must proceed in both cases. I see nothing wrong with using # in that case. Yes, you could also write
public function foo ($array) {
$bar = isset ($array[0]) ? $array[0] : null;
// do something with $bar
}
but I find that only marginally better. To me, code readability and brevity are values in and of themselves, and bloating the code with isset-tests just out of principle to me is a little silly.
Of course, if I am not mistaken, using # takes a tiny bit more time to execute that an isset-test, but let's be honest: how much of our code is truly performance critical? In a loop that is executed a bazillion times, I would probably use isset instead, but in most cases, it makes no difference to the user.

Why should I fix E_NOTICE errors?

As a developer, I work with E_NOTICE turned on. Recently though, I was asked why E_NOTICE errors should be fixed. The only reason that I could come up with was that it is best practice to correct those problems.
Does anyone else have any reasons to justify the extra time/cost spent to correct these problems?
More specifically, why should a manager spend the money to have these fixed if the code already works?
SUMMARY
The PHP Runtime Configuration Docs give you some idea why:
Enabling E_NOTICE during development has some benefits.
For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging.
NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.
Here's a more detailed explanation of each...
1. TO DETECT TYPOS
The main cause of E_NOTICE errors is typos.
Example - notice.php
<?php
$username = 'joe'; // in real life this would be from $_SESSION
// and then much further down in the code...
if ($usernmae) { // typo, $usernmae expands to null
echo "Logged in";
}
else {
echo "Please log in...";
}
?>
Output without E_NOTICE
Please log in...
Wrong! You didn't mean that!
Output with E_NOTICE
Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...
In PHP, a variable that doesn't exist will return null rather than causing an error, and that could cause code to behave differently than expected, so it's best to heed E_NOTICE warnings.
2. TO DETECT AMBIGUOUS ARRAY INDEXES
It also warns you about array indexes that might change on you, e.g.
Example - code looks like this today
<?php
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
Output without E_NOTICE
fred
Example - tomorrow you include a library
<?php
// tomorrow someone adds this
include_once('somelib.php');
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
and the library does something like this:
<?php
define("username", "Mary");
?>
New output
Empty, because now it expands to:
echo $arr["Mary"];
and there is no key Mary in $arr.
Output with E_NOTICE
If only the programmer had E_NOTICE on, PHP would have printed an error message:
Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred
3. THE BEST REASON
If you don't fix all the E_NOTICE errors that you think aren't errors, you will probably grow complacent, and start ignoring the messages, and then one day when a real error happens, you won't notice it.
Because an E_NOTICE indicates an error.
PHP is just too forgiving to call it that.
For example, accessing an undefined variable produces an E_NOTICE.
If this happens often, for example because you're not initializing your variables correctly, and your app is throwing notices all over the place, how are you going to tell the difference between a "variable that works just fine uninitialized" and times when you have really fat-fingered a variable name?
This may trigger a notice but will work as intended, so you ignore the notice:
if ($_GET['foo']) ...
This, on the other hand, will waste half your day while you ignore the notice and are trying to figure out why your "bar() function doesn't work":
$foo = bar();
if ($too) ...
If you don't "fix" the former case, where the variable may legitimately not exist, you can't meaningfully use notices to catch the typo in the second case.
Notices are there to help you debug your app. If you ignore them, you're only making your own life more difficult.
This kind of errors are good practice to fix, as they are what we call "code smell" they hint of another problem (like mistyped variable names or usage of undefined variables/wrong usage of methods) , or they will probably cause bugs down the road when you reflector/expand the system.
Of course, what I said here is not true 100% of the cases.
Ben I think this is an excellent question. True, it is a good practice to follow to attempt to correct any and all errors, even non-fatal ones, unless doing to would impede the designed (and thus desired) functionality of the system. Moreover, any level of error indicates that either:
a) There is something wrong with your code, or,
b) You have written code that is deprecated, or have written code that is otherwise unstable and thus prone to side effects.
Therefore, I believe that if the timeline and budget of a project allows you to do so, you should always strive to correct as many errors as possible, even if they are minor in terms of their impact on the final product.
Of course, there is a certain level of risk acceptance involved in cost-benefit analysis, so it may very well be the case that the managers overseeing the outcome of the project are willing to hedge the potential future cost of fixing a known issue against the present time and cost savings associate with not fixing an error. The math basically works out the way you think it would: If the PV of the cost of fixing the error in the future is less than the money saved today by not fixing the error, then you should not fix it. On the other hand, if the PV of the cost of fixing the error in the future is greater than the money saved today by not fixing it, then you should fix it today.
That, really, is the justification for (or against) fixing an error today, regardless of the error level.
Often they're indicative of logic errors or typos. They'll help you spot situations where you've mistyped a variable name or are trying to use a variable before it's been set.
I've also seen arguments that it's more efficient to avoid errors

PHP and undefined variables strategy

I am a C++ programmer starting with PHP. I find that I lose most of the debugging time (and my selfesteem!) due to undefined variables. From what I know, the only way to deal with them is to watch the output at execution time.
Are other strategies to notice these faults earlier (something like with C++ that a single compile gives you all the clues you need)?
This is a common complaint with PHP. Here are some ideas:
Use a code analysis tool. Many IDEs such as NetBeans will help also.
Just run the code. PHP doesn't have an expensive compilation step like C++ does.
Use unit testing. Common side effects include: better code.
Set error_reporting(-1), or the equivalent in your ini file.
Get xdebug. It's not preventative, but stack traces help with squishing bugs.
isset(), === null (identity operator), and guard clauses are your friends.
Loose and dynamic typing are a feature of the language. Just because PHP isn't strict about typing doesn't mean you can't be. If it really bugs you and you have a choice, you could try Python instead—it's a bit stricter with typing.
Log your E_NOTICE messages to a text file. You can then process logs with automated scripts to indicate files and lines where these are raised.
No. In PHP, you can only know a variable doesn't exist when you try to access it.
Consider:
if ($data = file('my_file.txt')) {
if (count($data) >= 0)
$line = reset($data);
}
var_dump($line);
You have to restructure your code so that all the code paths leads to the variable defined, e.g.:
$line = "default value";
if ($data = file('my_file.txt')) {
if (count($data) >= 0)
$line = reset($data);
}
var_dump($line);
If there isn't any default value that makes sense, this is still better than isset because you'll warned if you have a typo in the variable name in the final if:
$line = null;
if ($data = file('my_file.txt')) {
if (count($data) >= 0)
$line = reset($data);
}
if ($line !== null) { /* ... */ }
Of course, you can use isset1 to check, at a given point, if a variable exists. However, if your code relies on that, it's probably poorly structured. My point is that, contrary to e.g. C/Java, you cannot, at compile time, determine if an access to a variable is valid. This is made worse by the nonexistence of block scope in PHP.
1 Strictly speaking, isset won't tell you whether a variable is set, it tell if it's set and is not null. Otherwise, you'll need get_defined_vars.
From what I know the only way to deal with them is to watch the output at execution time.
Not really: To prevent these notices from popping up, you just need to make sure you initialize variables before accessing them the first time. We (sadly IMO) don't have variable declaration in PHP, but initializing them in the beginning of your code block is just as well:
$my_var = value;
Using phpDocumentor syntax, you can also kind of declare them to be of a certain a type, at least in a way that many IDEs are able to do code lookup with:
/** #desc optional description of what the variable does
#var int */
$my_var = 0;
Also, you can (and sometimes need to) use isset() / empty() / array_key_exists() conditions before trying to access a variable.
I agree this sucks big time sometimes, but it's necessary. There should be no notices in finished production code - they eat up performance even if displaying them is turned off, plus they are very useful to find out typos one may have made when using a variable. (But you already know that.)
Just watch not to do operations that requires the variable value when using it the first time, like the concatenate operator, .=.
If you are a C++ programmer you must be used to declare all variables. Do something similar to this in PHP by zeroing variables or creating empty array if you want to use them.
Pay attention to user input, and be sure you have registered globals off and check inputs from $_GET and $_POST by isset().
You can also try to code classes against structural code, and have every variable created at the beginning of a class declaration with the correct privacy policy.
You can also separate the application logic from the view, by preparing all variables that have to be outputted first, and when it goes to display it, you will be know which variables you prepared.
During development stages use
error_reporting(E_ALL);
which will show every error that has caused, all NOTICE errors, etc.
Keep an eye on your error_log as well. That will show you errors.
Use an error reporting system, example:
http://php.net/manual/en/function.set-error-handler.php
class ErrorReporter
{
public function catch($errno, $errstr, $errfile, $errline)
{
if($errno == E_USER_NOTICE && !defined('DEBUG'))
{
// Catch all output buffer and clear states, redirect or include error page.
}
}
}
set_error_handler(array(new ErrorReporter,'catch'));
A few other tips is always use isset for variables that you may / may not have set because of a if statement let’s say.
Always use if(isset($_POST['key'])) or even better just use if(!empty($_POST['key'])) as this checks if the key exists and if the value is not empty.
Make sure you know your comparison operators as well. Languages like C# use == to check a Boolean state whereas in PHP to check data-types you have to use === and use == to check value states, and single = to assign a value!
Unless I'm missing something, then why is no one suggesting to structure your page properly? I've never really had an ongoing problem with undefined variable errors.
An idea on structuring your page
Define all your variables at the top, assign default values if necessary, and then use those variables from there. That's how I write web pages and I never run into undefined variable problems.
Don't get in the habit of defining variables only when you need them. This quickly creates spaghetti code and can be very difficult to manage.
No one likes spaghetti code
If you show us some of your code we might be able to offer suggestions on how you can better structure it to resolve these sorts of errors. You might be getting confused coming from a C background; the flow may work differently to web pages.
Good practice is to define all variable before use, i.e., set a default value:
$variable = default_value;
This will solve most problems. As suggested before, use Xdebug or built-in debugging tools in editors like NetBeans.
If you want to hide the error of an undefined variable, then use #. Example: #$var
I believe that various of the Code Coverage tools that are available for PHP will highlight this.
Personally, I try and set variables, even if it's with an empty string, array, Boolean, etc. Then I use a function such as isset() before using them. For example:
$page_found = false;
if ($page_found==false) {
// Do page not found stuff here
}
if (isset($_POST['field'])) {
$value = $_POST['field'];
$sql = "UPDATE table SET field = '$value'";
}
And so on. And before some smart-ass says it: I know that query's unsafe. It was just an example of using isset().
I really didn't find a direct answer already here. The actual solution I found to this problem is to use PHP Code Sniffer along with this awesome extension called PHP Code Sniffer Variable Analysis.
Also the regular PHP linter (php -l) is available inside PHP Code Sniffer, so I'm thinking about customizing my configuration for regular PHP linting, detecting unused/uninitialized variables and validating my own code style, all in one step.
My very minimal PHPCS configuration:
<?xml version="1.0"?>
<ruleset name="MyConfig">
<description>Minimal PHP Syntax check</description>
<rule ref="Generic.PHP.Syntax" />
<rule ref="VariableAnalysis" />
</ruleset>

Categories