strip_tags - Sintaxis PHP que verifica el control previo a la fuente

strip_tags()

Question

¿Hay un analizador de código estático [como Lint] para los archivos PHP? - Estoy buscando cómo evaluar el contenido de los archivos PHP antes de que los desarrolladores los comprometan. Cualquiera que sea la (s) solución (es) apropiada (s) se activará a través de los ganchos de SVN similares a la respuesta: ¿Es posible verificar la sintaxis del archivo PHP desde PHP?

Me encontré con esta comprobación de sintaxis automática de los archivos PHP al verificar en SVN, que es el ángulo que estoy buscando, sin embargo ... php -l no es suficiente.

Por ejemplo, dado el código:

if ($foo == ''bar'') {
echo $foo;
}

Esto resulta en:

15/01/2012 02:51:14 [error] 694 # 0: * 164 FastCGI enviado en stderr: "Aviso de PHP: Variable indefinida: foo

Comparado con:

if (isset($foo)) { echo $foo; }

Parte de esto se reduce a educar a los programadores sobre las mejores prácticas. Desafortunadamente, algunos no aprenden tan rápido como otros, y la única manera de garantizar el cumplimiento de los estándares de codificación es reducir lo que entra en SVN que no se ha probado o no es compatible.

Desde el primer enlace en esta pregunta, he intentado:

• php -l
  • no notifica sobre el problema con $foo
• phplint-pure-c-1.0_20110223 - PHPLint
  • no notifica sobre el problema con $foo

 if ($foo == ''bar'') {
/_ HERE

==== /mnt/hgfs/workspace/scratch-pad/phpinfo.php:44: Advertencia: comparar (desconocido) == (cadena): no se puede verificar la comparación entre tipos desconocidos

• phpcs - Sniffer de código PHP
  • no notifica sobre el problema con $foo pesar de que PHP Sanity Check indica que fue la respuesta correcta
• SimpleTest
  • Es muy bueno, pero requiere que los desarrolladores que escriben el código incorrecto escriban buenas pruebas de unidad ...

Todos son interesantes a su manera, pero ninguno detecta estos problemas que realmente solo se encuentran en tiempo de ejecución.

Apreciar las opiniones / pensamientos sobre este tema.

EDITAR

Hubo un cartel que sugirió que PHPLint era el camino correcto a seguir. Pensé, OK! phplint-pure-c-1.1_20120202 nuevo dado que hay una nueva versión: phplint-pure-c-1.1_20120202 :

 <?php
if ($foo == ''bar'') {
echo $foo;
}
?>

Prueba simple .................... y, funciona e informa 1 error, 1 advertencia. Sin embargo, si se agrega lo siguiente ANTES de la declaración if :

 <?php
if (isset($foo) && $foo == ''bar'') { echo ''man''; }
if ($foo == ''bar'') {
echo $foo;
}
?>

no funciona , e informa 0 errores, 2 advertencias.

Answer 1

¿Podría utilizar un compilador de terceros que tenga más opciones de tiempo de compilación, como phc ( http://www.phpcompiler.org/doc/latest/runningphc.html#compiling-web-applications )? (¿o posiblemente hiphop?)

Entonces pensé: necesitas Perl :: Critic para php.

¿Criticando PHP-code / PerlCritic para PHP?

(también Google: crítico perl para php)

Ojalá pudiera ser más concretamente útil, pero a veces es solo una idea que te lleva a la solución. Eso es lo que tengo que ofrecer :)

David

Answer 2

Creo que esto podría ser un poco difícil para un analizador dar advertencias. El código que ha proporcionado podría funcionar con la ayuda register_globals, por ejemplo. Además, podría definirse en algún otro archivo que incluya este archivo. Por esas razones, los archivos PHP deben analizarse con el contexto completo de otros archivos para que esto sea realmente confiable, y la configuración de PHP / servidor también debe estar disponible o definida para el mecanismo de análisis.

Dicho esto, ¿estás seguro de que phplint no hace lo que quieres?

Hay un validador en línea que puede usar para probarlo. Dada la entrada:

<?php
echo $foo;

el resultado fue:

 echo $foo;
/_ HERE
==== 3: ERROR: variable `$foo'' has not been assigned
END parsing of test-qBlPWw
==== ?: notice: unused package `dummy.php''
==== ?: notice: unused module `standard''
Overall test results: 1 errors, 0 warnings.

mientras que con isset () no encontró ningún problema.

EDITAR: para este otro caso de prueba:

<?php
if ($foo == ''bar'') echo $foo;

En Linux Mint 8 la respuesta es:

$ src/phplint test.php
/home/vadmin/phplint/phplint-pure-c-1.0_20110223/test.php:3: ERROR: variable `$foo'' has not been assigned
/home/vadmin/phplint/phplint-pure-c-1.0_20110223/test.php:3: Warning: comparing (unknown) == (string): cannot check the comparison between unknown types
Overall test results: 1 errors, 1 warnings.

y con esto:

<?php
$foo = ''1'';
if ($foo == 1) echo $foo;

es:

$ src/phplint test.php
/home/vadmin/phplint/phplint-pure-c-1.0_20110223/test.php:6: ERROR: comparing (string) == (int)
Overall test results: 1 errors, 0 warnings.

entonces, ¿no está funcionando como debería y reportando el problema correctamente?

Answer 3

Es posible que desee combinar phpcs (para cumplir con los estándares de codificación) y un nuevo proyecto de Sebastian Bergmann: https://github.com/sebastianbergmann/hphpa Utiliza el compilador estático de Facebook para buscar errores como los que usted busca. . Podría ser demasiado como un gancho precompromiso, pero un gancho en su sistema de compilación podría ser suficiente?

Answer 4

Oh, sí, lo que necesitas es PHPUnderControl. Verificará tu sintaxis, chackará automáticamente tus pruebas de unidad, hará un índice de CRAP y más cosas buenas. Básicamente es la bomba!

Compruébalo, aquí está la URL: http://phpundercontrol.org/

Answer 5

Todas estas herramientas superpotentes inteligentes que escuchan a hurtadillas cada puerta y miran a cada ojo de la cerradura nunca podrán competir con la estúpida y contundente acción de EJECUTAR el código.

¿Cuál es el valor de tener archivos php sintácticamente válidos compilables en el repositorio? Puedes hacer zounds de dichos archivos, comprometerlos regularmente con el repositorio y, estar seguro, todos ellos contribuyen al proyecto y agregar una cierta característica confiable, porque, bueno, pasaron por el enlace precompromiso para verificar su validez?

Hay una gran cantidad de problemas con el código escrito por humanos, la sintaxis y los vars faltantes son solo la punta del iceberg. Las pruebas unitarias (según lo observado por @NikiC) ayudan bastante. Es responsabilidad del desarrollador crear un código confiable, que funcione, documentado y probarlo antes de comprometerse. Los errores tontos de usar vars no declarados es algo que el IDE puede señalar (por ejemplo, Zend Studio lo hace). Su objetivo es crear un buen software de trabajo y las pruebas de unidad son clave aquí. Esta debería ser la principal preocupación en mi opinión. Los archivos php válidos son un requisito muy flexible ...

Answer 6

aunque no es un verificador de línea de comando, PHPStorm tiene que ser uno de los mejores IDE que hay.

Tiene varias inspecciones que pueden detectar el tipo de problemas que ha mencionado. Además, vuelve a ejecutar automáticamente estas inspecciones en los archivos que está comprometiendo con el control de versiones, verificando variables indefinidas, código de mala calidad y "todos".

Sin embargo, el problema con estas inspecciones es que no pueden saber todo, por lo que a veces se equivocan al ser "sugerencias" o "advertencias" en lugar de error.

Sin embargo, es bastante bueno en lo que hace, y puede tener este tipo de problemas durante la edición y, por lo general, da como resultado corregir los errores mucho antes de cualquier acción de compromiso.