E_ALL compilance
Yorirou - April 27, 2009 - 12:03
| Project: | Patterns |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
I got a rid of some notices.
| Attachment | Size |
|---|---|
| patterns.patch | 1.59 KB |
#1
I think this is not visible right now
#2
Yeah, me too. I got HEAPS of notices when trying to use patterns in an install profile.
The above patch has a few tabs in (naughty when doing compliance ;)
Here's my version of the same fixes, rolled today. I got EXACTLY the same points of notice as Yorirou .. plus one more.
#3
Re-roll.
It's not much fun to work with if my dev copy is going to remain out-of sync with the CVS copy. This means I can't submit any other patches until the code style is cleaned up.
#4
thanks for trying to clean these up.
Is this portion in there a related bugfix too?
@@ -930,7 +931,7 @@ function patterns_get_patterns($reset =
$result = db_query('SELECT file FROM {patterns} WHERE status = 1');
while ($pattern = db_fetch_object($result)) {
- $enabled[] = $result->file;
+ $enabled[] = $pattern->file;
}
$priority = array();
#5
It's a fix, it also triggered a strict warning, but to fix it meant repairing the logic also. $result->file is always undefined.
Looked like a typo that got overlooked to me.
Review the logic and see what you think, but I can't see how a db result object could ever have a ->file property, or why you would loop over all $patterns but do nothing with the values found.
This is one of those cases where turning on strict actually does expose some corners of the code that needed review. I think.