PHP validity checker
-
Greetings,
There seem to be a "never-ending" trickle of bugs that are found that are simply typos of function or variable names. The latest is https://github.com/pfsense/pfsense/commit/7fd38f44ba327ab1cd1cad3ac76ebb169ccb12e0
Somehow when a module is loaded, the PHP parser does not go through the whole thing and find any function calls that are to unknown function names. So it waits until the particular code path is traversed before the error appears.
Also there is the problem that in PHP a var does not have to be declared before being used, so a typo in a var name just results in the data being blank, and the code barrels on until something bad happens or the system does something, but not quite what was wanted.
It would be good to find all these "dumb" errors and fix them.Are there some tools somewhere that can parse the whole system and report references to unknown function names, and suspect vars?
-
Some of the css files can also use some tidy-ing.
I put the pfsense_ng theme "all.css" and "login.css" through csstidy1.3 using a site called http://devilo.us/ and save them back in to my pfsense.
advanced options:-
Compression = Medium (balanced)
-
Optimise shorthand = Yes, common+fonts
-
Discard invalid properties = CSS 3 compatible
-
Preserve comments = On
Not only are they smaller, but the browsers complain less.
Some of the links to javascript and theme-files could use a fixed location instead of relative.
In "system.inc" I change "./themes/" to "/themes/" for 3 instances.
In "fbegin.inc" I change "javascript/domTT/" to "**/**javascript/domTT/" for 4 instances @ line 348.For the status page in unbound I change the status width to 88 from 101 to fit the pfsense_ng theme better.
Alas I don't know of any tools to help with php development other than being carefull and maybe create a list of all the reused variable names so you use the correct naming convention.
-
-
Could move to a higher error reporting level and clean it up and leave that as the norm maybe
http://php.net/manual/en/function.error-reporting.php
A quick look around:
http://www.icosaedro.it/phplint/phplint-on-line.html
http://www.meandeviation.com/tutorials/learnphp/php-syntax-check/v5-3/syntax-check.php
http://www.piliapp.com/php-syntax-check/
Depends on error_reporting level php -l <filename></filename>Using an IDE that is aware of what you are doing would certainly make it harder to type in something wrong.
-
…the browsers complain less.
How do you mean that? I didn't see any complain so far from my Firefox, however, I'm still interested of what I don't notice…
-
Unfortunatley, no.
The only validator is php -l but it does not go through the code path.
The alternative is to use unit testing but with php that is such a big mess.
-
…the browsers complain less.
How do you mean that? I didn't see any complain so far from my Firefox, however, I'm still interested of what I don't notice…
Chrome : Left mouse button "inspect element".
Firefox: Left mouse button "Inspect element (Q)".Example of Devilo.us Parser log:
99 Removed invalid property: filter 100 Removed invalid property: -moz-opacity 119 Removed invalid property: -moz-opacity 125 Removed invalid property: filter 126 Removed invalid property: -moz-opacity 140 Removed invalid property: -moz-opacity 146 Removed invalid property: align 459 Removed invalid property: filter 460 Removed invalid property: -moz-opacity 472 Added semicolon to the end of declaration 533 Added semicolon to the end of declaration 547 Removed invalid property: filter 548 Removed invalid property: -moz-opacity 1247 Added semicolon to the end of declaration 1368 Removed invalid property: <--background-color 1369 Removed invalid property: thiscausinglightgrayrectanglestotherightofmanytablesingui--padding-right Optimised color: Changed '#990000' to '#900' Optimised color: Changed 'white' to '#fff' Optimised color: Changed '#FFD9D1' to '#ffd9d1' Optimised color: Changed '#000000' to '#000' Optimised color: Changed '#333333' to '#333' Optimised color: Changed '#FFFFFF' to '#fff' Optimised number: Removed unit 'px' from '0px' Optimised color: Changed '#550000' to '#500' Optimised color: Changed '#666666' to '#666' Optimised color: Changed '#eeeeee' to '#eee' Optimised color: Changed '#ffffff' to '#fff' Optimised color: Changed 'black' to '#000' Optimised color: Changed '#777777' to '#777' Optimised color: Changed '#DDDDDD' to '#ddd' Optimised color: Changed '#999999' to '#999' Optimised color: Changed '#FFFFC6' to '#ffffc6' Optimised color: Changed '#CC0000' to '#c00' Optimised color: Changed '#A0A0A0' to '#a0a0a0' Optimised color: Changed '#BBBBBB' to '#bbb' Optimised color: Changed '#D9DEE8' to '#d9dee8' Optimised color: Changed '#EEEEEE' to '#eee' Optimised color: Changed '#3366cc' to '#36c' Optimised color: Changed '#cccccc' to '#ccc' Optimised number: Removed unit 'em' from '0em' Optimised color: Changed '#B1B1B1' to '#b1b1b1' Optimised color: Changed '#CCCCCC' to '#ccc' Optimised number: Removed unit '%' from '0%' Fixed invalid color name: Changed 'LimeGreen' to '#32cd32' Optimised color: Changed 'LimeGreen' to '#32cd32'
-
I suspect if you cranked up PHP's logging you'd possibly find some such issues, but you'd have to parse through so much noise I'm not sure that would be effective.
One would think there are static analysis tools that would find things along those lines, and there probably are. I haven't had a chance to look for that specifically. The static analysis I do on our code base is security-focused.
-
At one time we talked about a git hook that would reject a push if it failed a simple "php -l" validation. It's not perfect, but it would catch common mistakes/obvious typos.
