unexpected thrown que parseerror parse expecting error end php parsing debugging syntax-error

thrown - Errores de sintaxis/análisis PHP; ¿Y cómo resolverlos?



syntax error, unexpected '';'' (15)

Todo el mundo se ejecuta en los errores de sintaxis. Incluso los programadores experimentados hacen errores tipográficos. Para los recién llegados es solo una parte del proceso de aprendizaje. Sin embargo, a menudo es fácil interpretar mensajes de error como:

Error de análisis de PHP: error de sintaxis, ''{'' inesperado en index.php en la línea 20

El símbolo inesperado no es siempre el verdadero culpable. Pero el número de línea da una idea aproximada de dónde empezar a buscar.

Siempre mira el contexto del código . El error de sintaxis a menudo se oculta en las líneas de código mencionadas o en las anteriores . Compare su código con ejemplos de sintaxis del manual.

Si bien no todos los casos coinciden con el otro. Sin embargo, hay algunos pasos generales para resolver errores de sintaxis . Estas referencias resumen los escollos comunes:

Referencias estrechamente relacionadas:

Y:

Si bien Stack Overflow también da la bienvenida a los programadores novatos, se dirige principalmente a preguntas de programación profesional.

  • Responder a los errores de codificación de todos y los errores tipográficos estrechos se considera en su mayoría fuera de tema.
  • Por lo tanto, tómese el tiempo para seguir los pasos básicos , antes de publicar solicitudes de corrección de sintaxis.
  • Si aún tiene que hacerlo, muestre su propia iniciativa de resolución, intentos de corrección y su proceso de pensamiento sobre lo que parece o puede estar mal.

Si su navegador muestra mensajes de error como "SyntaxError: carácter ilegal", entonces no está realmente relacionado con php , sino un error de sintaxis de javascript .

Errores de sintaxis generados en el código del proveedor: Finalmente, considere que si el error de sintaxis no se produjo al editar su base de código, pero después de la instalación o actualización de un paquete de un proveedor externo, podría deberse a una incompatibilidad de la versión de PHP, por lo que debe verificar los requisitos del proveedor en la configuración de su plataforma .

Inesperado (

Los paréntesis de apertura normalmente siguen construcciones de lenguaje como if / foreach / for / array / list o comienzan una expresión aritmética. Son sintácticamente incorrectos después de "strings" , una anterior () , una única $ , y en algunos contextos de declaración típicos.

  1. Parámetros de declaración de funciones

    Una ocurrencia más rara para este error es tratar de usar expresiones como parámetros de función predeterminados . Esto no es compatible, incluso en PHP7:

    function header_fallback($value, $expires = time() + 90000) {

    Los parámetros en una declaración de función solo pueden ser valores literales o expresiones constantes. A diferencia de las invocaciones de funciones, donde puedes usar libremente whatever(1+something()*2) etc.

  2. Valores predeterminados de propiedad de clase

    Lo mismo para las declaraciones de miembros de clase , donde solo se permiten valores literales / constantes, no expresiones:

    class xyz { ⇓ var $default = get_config("xyz_default");

    Pon esas cosas en el constructor. Vea también ¿Por qué los atributos de PHP no permiten funciones?

    De nuevo, tenga en cuenta que PHP 7 solo permite var $xy = 1 + 2 +3; Expresiones constantes allí.

  3. Sintaxis de JavaScript en PHP

    El uso de JavaScript o la sintaxis jQuery no funcionará en PHP por razones obvias:

    <?php ⇓ print $(document).text();

    Cuando esto sucede, generalmente indica una cadena precedente sin terminar; y las secciones <script> literales que se filtran al contexto del código PHP

  4. isset (()), vacío, clave, siguiente, actual

    Tanto isset() como empty() son incorporaciones de idioma, no funciones. Necesitan acceder a una variable directamente . Si inadvertidamente agrega un par de paréntesis demasiado, entonces creará una expresión sin embargo:

    ⇓ if (isset(($_GET["id"]))) {

    Lo mismo se aplica a cualquier construcción de lenguaje que requiera acceso implícito al nombre de la variable. Estos elementos incorporados son parte de la gramática del lenguaje, por lo tanto, no permiten paréntesis adicionales decorativos.

    Las funciones de nivel de usuario que requieren una referencia variable, pero obtienen un resultado de expresión pasado, conducen a errores de tiempo de ejecución.


Inesperado )

  1. Parámetro de función ausente

    No puede haber comas perdidas en último lugar en una llamada de función . PHP espera un valor allí y, por lo tanto, se queja de un )paréntesis de cierre temprano .

    ⇓ callfunc(1, 2, );

    Una coma final solo se permite en array()o list()construye.

  2. Expresiones inconclusas

    Si olvidas algo en una expresión aritmética, el analizador se da por vencido. Porque ¿cómo debería interpretar eso?

    ⇓ $var = 2 * (1 + );

    Y si olvidó el cierre )incluso, entonces recibiría una queja sobre el punto y coma inesperado en su lugar.

  3. Foreach como constant

    Para los prefijos de variables olvidadas $en las declaraciones de control , verá:

    ↓ ⇓ foreach ($array as wrong) {

    PHP a veces te dice que esperaba un ::lugar. Debido a que una variable class :: $ podría haber satisfecho la expresión $ variable esperada ..


Inesperado {

Aparecen llaves {y }encierran bloques de código. Y los errores de sintaxis sobre ellos generalmente indican algún anidamiento incorrec.

  1. Subexpresiones inigualables en una if

    Lo más común es que esté desequilibrado (y) sea ​​la causa si el analizador se queja de que la apertura de rizado {aparece demasiado pronto. Un ejemplo simple:

    ⇓ if (($x == $y) && (2 == true) {

    Cuente sus parens o use un IDE que ayude con eso. Tampoco escriba código sin espacios. La legibilidad cuenta.

  2. {y} en el contexto de expresión

    No puedes usar llaves en las expresiones. Si confunde paréntesis y rizos, no se ajustará a la gramática del lenguaje:

    ⇓ $var = 5 * {7 + $x};

    Hay algunas excepciones para la construcción del identificador, como la variable de alcance local ${references}.

  3. Variables variables o expresiones var rizadas

    Esto es bastante raro. Pero también puede obtener {y }analizar las quejas de expresiones variables complejas:

    ⇓ print "Hello {$world[2{]} !";

    Aunque hay una mayor probabilidad de un inesperado }en tales contextos.


Inesperado }

Al obtener un }error "inesperado ", casi siempre ha cerrado un bloque de código demasiado pronto.

  1. Última declaración en un bloque de código

    Puede ocurrir para cualquier expresión no terminada.

    Y si la última línea en un bloque de función / código carece de un ;punto y coma final :

    function whatever() { doStuff() } ⇧

    En este caso, el analizador no puede decir si es posible que aún desee agregar algo + 25;al resultado de la función o alguna otra cosa.

  2. Bloqueo anidado inválido / Olvidado {

    A veces verá este error del analizador cuando un bloque de código se }cerró demasiado pronto, o {incluso olvidó una apertura :

    function doStuff() { if (true) ⇦ print "yes"; } } ⇧

    En el fragmento anterior ifno tenía una {llave de apertura . Así, el cierre de }abajo se volvió redundante. Y, por lo tanto, el siguiente cierre }, que estaba destinado a la función, no era asociable a la {llave de apertura original .

    Tales errores son aún más difíciles de encontrar sin la sangría apropiada del código. Utilice un IDE y la coincidencia de soporte.


Inesperado {, esperando(

Las construcciones de lenguaje que requieren un encabezado de condición / declaración y un bloque de código activarán este error.

  1. Listas de parámetros

    Por ejemplo, no se permiten funciones mal definidas sin lista de parámetros :

    ⇓ function whatever { }

  2. Condiciones de declaración de control

    Y tampoco puedes tener un ifsin condición .

    ⇓ if { }

    Lo que no tiene sentido, obviamente. Lo mismo para los sospechosos habituales, for/ foreach, while/ do, etc.

    Si tienes este error en particular, definitivamente deberías buscar algunos ejemplos manuales.

Inesperado [

En estos días, el inesperado [ array bracket se ve comúnmente en versiones de PHP obsoletas. La sintaxis de matriz corta está disponible desde PHP > = 5.4 . Las instalaciones anteriores solo admiten array() .

$php53 = array(1, 2, 3); $php54 = [1, 2, 3]; ⇑

La desreferenciación del resultado de la función de matriz tampoco está disponible para versiones anteriores de PHP:

$result = get_whatever()["key"]; ⇑

Referencia - ¿Qué significa este error en PHP? - "Error de sintaxis, inesperado /[ " muestra las soluciones más comunes y prácticas.

Sin embargo, siempre es mejor actualizar su instalación de PHP. Para planes de alojamiento web compartidos, primero investigue si, por ejemplo, SetHandler php56-fcgi se puede usar para habilitar un tiempo de ejecución más nuevo.

Ver también:

Por cierto, también hay preprocesadores y convertidores descendentes de sintaxis de PHP 5.4 si usted es realmente pegajoso con versiones de PHP más antiguas + más lentas.

Otras causas de inesperados [ errores de sintaxis

Si no es la discrepancia de la versión de PHP, a menudo es un error de sintaxis de error tipográfico o de recién llegado:

  • No puede usar declaraciones / expresiones de propiedad de matriz en clases , ni siquiera en PHP 7.

    protected $var["x"] = "Nope"; ⇑

  • Confundir [ con la apertura de llaves { o paréntesis ( es un descuido común.

    foreach [$a as $b) ⇑

    O incluso:

    function foobar[$a, $b, $c] { ⇑

  • O intentando desreferenciar las constantes (antes de PHP 5.6) como matrices:

    $var = const[123]; ⇑

    Al menos PHP interpreta esa const como un nombre constante.

    Si pretendía acceder a una variable de matriz (que es la causa típica aquí), a continuación, agregue el $ sigil $varname - para que se convierta en $varname .


Inesperado ] cerrando corchete

Esto es algo más raro, pero también hay accidentes de sintaxis con el corchete de la matriz de terminación ] .

  • Nuevamente, los desajustes con ) paréntesis o } llaves son comunes:

    function foobar($a, $b, $c] { ⇑

  • O tratando de terminar una matriz donde no hay una:

    $var = 2];

    Lo que ocurre a menudo en declaraciones de matrices anidadas y multilínea .

    $array = [1,[2,3],4,[5,6[7,[8],[9,10]],11],12]],15]; ⇑

    Si es así, use su IDE para la coincidencia de corchetes para encontrar cualquier cierre prematuro de la matriz. Por lo menos use más espacio y líneas nuevas para reducirlo.

Inesperado T_CONSTANT_ENCAPSED_STRING
Inesperado T_ENCAPSED_AND_WHITESPACE

Los nombres T_CONSTANT_ENCAPSED_STRING manejar T_CONSTANT_ENCAPSED_STRING y T_ENCAPSED_AND_WHITESPACE refieren a literales de "string" citados.

Se utilizan en diferentes contextos, pero el problema de sintaxis es bastante similar. Las advertencias de T_ENCAPSED… ocurren en el contexto de cadenas de doble comillas, mientras que las cadenas de caracteres T_CONSTANT… a menudo se extravían en expresiones o declaraciones simples de PHP.

  1. Interpolación de variable incorrecta

    Y aparece con más frecuencia para la interpolación de variable incorrecta de PHP:

    ⇓ ⇓ echo "Here comes a $wrong[''array''] access";

    Citar claves de matrices es una necesidad en el contexto de PHP. Pero en cadenas entre comillas dobles (o HEREDOCs) esto es un error. El analizador se queja sobre la ''string'' comillas simples contenidas, porque generalmente espera un identificador / clave literal allí.

    Más precisamente, es válido usar una sintaxis simple de estilo PHP2 entre comillas dobles para referencias de matriz:

    echo "This is only $valid[here] ...";

    Sin embargo, las matrices anidadas o las referencias de objetos más profundas requieren la sintaxis de la expresión de cadena compleja :

    echo "Use {$array[''as_usual'']} with curly syntax.";

    Si no está seguro, esto es comúnmente más seguro de usar. A menudo incluso se considera más legible. Y los mejores IDE en realidad usan una distinta coloración de sintaxis para eso.

  2. Falta concatenación

    Si una cadena sigue a una expresión, pero carece de una concatenación u otro operador, entonces verá a PHP quejarse de la cadena literal:

    ⇓ print "Hello " . WORLD " !";

    Si bien es obvio para ti y para mí, PHP simplemente no puede adivinar que la cadena debía estar agregada allí.

  3. Citas de cadenas confusas

    El mismo error de sintaxis ocurre cuando se confunden los delimitadores de cadena . Una cadena iniciada por una comilla simple o doble también termina con la misma.

    ⇓ print "<a href="'' . $link . ''">click here</a>"; ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟

    Ese ejemplo comenzó con comillas dobles. Pero las comillas dobles también estaban destinadas a los atributos HTML. Sin embargo, el operador de concatenación previsto dentro se interpretó como parte de una segunda cadena entre comillas simples.

    Sugerencia : configure su editor / IDE para que use una coloración ligeramente distinta para las cadenas entre comillas simples y dobles. (También ayuda con la lógica de la aplicación a preferir, por ejemplo, cadenas entre comillas dobles para salida textual, y cadenas entre comillas simples solo para valores de tipo constante).

    Este es un buen ejemplo en el que no debería salir de las comillas dobles en primer lugar. En su lugar, simplemente use los escapes /" apropiados para las citas de los atributos HTML:

    print "<a href=/"{$link}/">click here</a>";

    Si bien esto también puede llevar a una confusión de sintaxis, todos los mejores IDE / editores ayudan nuevamente al colorear las comillas de escape de manera diferente.

  4. Falta la cita inicial

    Igualmente se olvida la apertura " / '' cita una receta para los errores del analizador:

    ⇓ make_url(login'', ''open'');

    Aquí, el '', '' se convertiría en un literal de cadena después de una simple palabra, cuando obviamente el login estaba destinado a ser un parámetro de cadena.

  5. Listas de arrays

    Si omite una coma en un bloque de creación de matriz, el analizador verá dos cadenas consecutivas:

    array( ⇓ "key" => "value" "next" => "....", );

    Tenga en cuenta que la última línea siempre puede contener una coma adicional, pero ignorar una en el medio es imperdonable. Lo que es difícil de descubrir sin resaltado de sintaxis.

  6. Lista de parámetros de funciones

    Lo mismo para llamadas a funciones :

    ⇓ myfunc(123, "text", "and" "more")

  7. Cuerdas fuera de control

    Una variante común son los terminadores de cadena olvidados:

    ⇓ mysql_evil("SELECT * FROM stuffs); print "''ok''"; ⇑

    Aquí PHP se queja de dos literales de cadena que se suceden directamente. Pero la verdadera causa es la cadena anterior no cerrada, por supuesto.

Ver también

Inesperado T_VARIABLE

Un " T_VARIABLE inesperado" significa que hay un nombre de $variable literal, que no se ajusta a la expresión actual / estructura de la declaración.

  1. Falta un punto y coma

    Lo más comúnmente indica un punto y coma que falta en la línea anterior. Las asignaciones de variables después de una declaración son un buen indicador de dónde buscar:

    ⇓ func1() $var = 1 + 2; # parse error in line +2

  2. Concatenación de cuerdas

    Un percance frecuente son las concatenaciones de cuerdas con olvidadas . operador:

    ⇓ print "Here comes the value: " $value;

    Por cierto, deberías preferir la interpolación de cadenas (variables básicas entre comillas dobles) siempre que eso ayude a la legibilidad. Lo que evita estos problemas de sintaxis.

    La interpolación de cadenas es una característica principal del lenguaje de scripting . No hay vergüenza en utilizarlo. Ignora cualquier consejo de micro-optimización sobre la variable . La concatenación es más rápida . No es.

  3. Operadores de expresión faltantes

    Por supuesto, el mismo problema puede surgir en otras expresiones, por ejemplo, operaciones aritméticas:

    ⇓ print 4 + 7 $var;

    PHP no puede adivinar aquí si la variable debería haber sido agregada, sustraída o comparada, etc.

  4. Liza

    Lo mismo para las listas de sintaxis, como en las poblaciones de matriz, donde el analizador también indica una coma esperada , por ejemplo:

    ⇓ $var = array("1" => $val, $val2, $val3 $val4);

    O funciones de listas de parámetros:

    ⇓ function myfunc($param1, $param2 $param3, $param4)

    De manera equivalente, ve esto con una list o enunciados global , o cuando carece de un ; punto y coma en un bucle for .

  5. Declaraciones de clase

    Este error del analizador también se produce en las declaraciones de clase . Solo puedes asignar constantes estáticas, no expresiones. Por lo tanto, el analizador se queja de las variables como datos asignados:

    class xyz { ⇓ var $value = $_GET["input"];

    En particular, las llaves de cierre no coincidentes pueden llevar aquí. Si un método se termina demasiado pronto (¡use la sangría apropiada!), Entonces una variable extraviada se colocará fuera del cuerpo de la declaración de la clase.

  6. Variables tras identificadores

    Además, nunca puedes tener una variable siguiendo un identificador directamente:

    ⇓ $this->myFunc$VAR();

    Por cierto, este es un ejemplo común donde la intención era utilizar variables variables, tal vez. En este caso, una búsqueda de propiedad variable con $this->{"myFunc$VAR"}(); por ejemplo.

    Tenga en cuenta que el uso de variables variables debe ser la excepción. Los recién llegados a menudo intentan usarlos de manera casual, incluso cuando los arreglos serían más simples y apropiados.

  7. Parentes que faltan después de construcciones de lenguaje

    La escritura rápida puede llevar a un paréntesis de apertura olvidado for declaraciones if y for y foreach :

    ⇓ foreach $array as $key) {

    Solución: agregue la apertura que falta ( entre la declaración y la variable).

  8. Else no espera condiciones.

    ⇓ else ($var >= 0)

    Solución: Eliminar las condiciones de else o usar elseif .

  9. Se necesitan soportes para el cierre.

    ⇓ function() uses $var {}

    Solución: Agregue corchetes alrededor de $var .

  10. Espacio en blanco invisible

    Como se mencionó en la respuesta de referencia en "Unicode perdido invisible" (como un espacio sin interrupciones ), también puede ver este error para el código confiado como:

    <?php ⇐ $var = new PDO(...);

    Es bastante frecuente en el inicio de archivos y para copiar y pegar códigos. Verifique con un hexeditor si su código no parece contener visualmente un problema de sintaxis.

Ver también

T_STRING inesperado

T_STRING es un nombre poco T_STRING . No se refiere a una "string" citada. Significa que se encontró un identificador en bruto. Esto puede abarcar desde palabras bare hasta nombres CONSTANT o de función sobrantes, cadenas sin comillas olvidadas o cualquier texto sin formato.

  1. Cuerdas mal citadas

    Sin embargo, este error de sintaxis es más común para valores de cadena incorrectamente citados. Cualquier cita no escapada y extraviada " o '' formará una expresión no válida:

    ⇓ ⇓ echo "<a href="http://example.com">click here</a>";

    El resaltado de sintaxis hará que tales errores sean muy obvios Es importante recordar usar barras diagonales inversas para /" comillas dobles o /' comillas simples /' , dependiendo de lo que se usó como encierro de cadena .

    • Por conveniencia, debería preferir las comillas simples externas al generar HTML sin formato con comillas dobles dentro.
    • Utilice cadenas entre comillas dobles si desea interpolar variables, pero luego fíjese si se escapan comillas dobles literales.
    • Para una salida más larga, prefiera múltiples líneas de echo / print lugar de escapar dentro y fuera. Mejor aún consideremos una sección de HEREDOC .

    Vea también ¿Cuál es la diferencia entre cadenas de comillas simples y comillas dobles en PHP? .

  2. Cuerdas no cerradas

    Si pierde un cierre " entonces un error de sintaxis generalmente se materializa más tarde. Una cadena no terminada a menudo consumirá un poco de código hasta el siguiente valor de cadena deseado:

    ⇓ echo "Some text", $a_variable, "and some runaway string ; success("finished"); ⇯

    No son solo los T_STRING literales que el analizador puede protestar entonces. Otra variación frecuente es un Unexpected ''>'' para HTML literal sin comillas.

  3. Comillas de cadena no programadas

    Si copia y pega código de un blog o sitio web, a veces terminará con un código no válido. Las citas tipográficas no son lo que PHP espera:

    $text = ’Something something..’ + ”these ain''t quotes”;

    Las comillas tipográficas / inteligentes son símbolos de Unicode. PHP los trata como parte del texto alfanumérico adjunto. Por ejemplo, ”these se interpreta como un identificador constante. Pero cualquier literal de texto siguiente se ve entonces como una palabra pelada / T_STRING por el analizador.

  4. El punto y coma faltante; otra vez

    Si tiene una expresión sin terminar en líneas anteriores, entonces cualquier declaración o construcción de lenguaje siguiente se verá como un identificador sin formato:

    ⇓ func1() function2();

    PHP simplemente no puede saber si pretendía ejecutar dos funciones después de otra, o si pretendía multiplicar sus resultados, agregarlos, compararlos o solo ejecutar uno || o el otro.

  5. Etiquetas abiertas cortas y encabezados <?xml en scripts PHP

    Esto es bastante raro. Pero si short_open_tags está habilitado, entonces no puede comenzar sus scripts PHP con una declaración XML :

    ⇓ <?xml version="1.0"?>

    PHP verá el <? y reclamarlo por sí mismo. No entenderá para qué estaba destinado el xml perdido. Se interpretará como constante. Pero la version será vista como otro literal / constante. Y dado que el analizador no puede dar sentido a dos literales / valores subsiguientes sin un operador de expresión en el medio, será un error del analizador.

  6. Personajes invisibles de Unicode

    Una de las causas más horribles de los errores de sintaxis son los símbolos Unicode, como el espacio de no separación . PHP permite los caracteres Unicode como nombres de identificadores. Si recibe una queja del analizador T_STRING por un código totalmente sospechoso como:

    <?php print 123;

    Necesitas romper con otro editor de texto. O incluso un hexeditor. Lo que parece espacios lisos y nuevas líneas aquí, puede contener constantes invisibles. Los IDE basados ​​en Java a veces son ajenos a una lista de materiales UTF-8, espacios de ancho cero, separadores de párrafos, etc. Intente reeditar todo, elimine los espacios en blanco y agregue espacios normales nuevamente.

    Se puede reducir con agregar redundante ; separadores de declaración en cada inicio de línea:

    <?php ;print 123;

    El extra ; el punto y coma aquí convertirá el carácter invisible anterior en una referencia constante indefinida (expresión como declaración). Lo que a cambio hace que PHP produzca un aviso útil.

  7. El signo `$` que falta delante de los nombres de variables

    Las variables en PHP están representadas por un signo de dólar seguido del nombre de la variable.

    El signo de dólar ( $ ) es un sigil que marca el identificador como nombre de una variable. Sin este sigilo, el identificador podría ser una palabra clave de lenguaje o una constant .

    Este es un error común cuando el código PHP fue "traducido" del código escrito en otro idioma (C, Java, JavaScript, etc.). En tales casos, una declaración del tipo de variable (cuando el código original fue escrito en un idioma que usa variables tipificadas) también podría escaparse y producir este error.

  8. Comillas escapadas

    Si usas / en una cadena, tiene un significado especial. Esto se denomina " carácter de escape " y normalmente le dice al analizador que tome el siguiente carácter literalmente.

    Ejemplo: echo ''Jim said /'Hello/'''; imprimirá Jim said ''hello''

    Si se escapa de la cita de cierre de una cadena, la cita de cierre se tomará literalmente y no según lo previsto, es decir, como una cita imprimible como parte de la cadena y no cerrará la cadena. Esto se mostrará como un error de análisis comúnmente después de abrir la siguiente cadena o al final de la secuencia de comandos.

    Error muy común al especificar rutas en Windows: "C:/xampp/htdocs/" es incorrecto. Necesita "C://xampp//htdocs//" .

$ Inesperado fin

Cuando PHP habla de un "inesperado $end", significa que su código terminó prematuramente. (El mensaje es un poco engañoso cuando se toma literalmente. No se trata de una variable llamada "$ end", como a veces suponen los recién llegados. Se refiere al "fin de archivo",. EOF)

Causa: desequilibrado {y }para bloques de código / y declaraciones de funciones o clases.

Es casi siempre sobre un faltante }llave de cierre para cerrar los bloques de código anterior.

  • Una vez más, utilice la sangría adecuada para evitar tales problemas.

  • Use un IDE con una coincidencia de corchetes para averiguar dónde }está mal. Hay atajos de teclado en la mayoría de los IDE y editores de texto:

    • NetBeans, PhpStorm, Komodo: Ctrl [yCtrl ]
    • Eclipse, Aptana: Ctrl Shift P
    • Átomo, sublime: Ctrl m- Zend StudioCtrl M
    • Geany, Notepad ++: Ctrl B- Joe: Ctrl G- Emacs: CMn- Vim:%

La mayoría de los IDE también resaltan llaves, corchetes y paréntesis. Lo que hace que sea bastante fácil inspeccionar su correlación:

Expresiones no terminadas

Y el Unexpected $enderror de sintaxis / analizador también puede ocurrir para expresiones o declaraciones no terminadas:

  • $var = func(1, ?> EOF

Entonces, mira el final de los scripts primero. Una cola ;es a menudo redundante para la última declaración en cualquier script de PHP. Pero deberías tener uno. Precisamente porque reduce los problemas de sintaxis.

Marcadores HEREDOC con sangría

Otra ocurrencia común aparece con las cadenas HEREDOC o NOWDOC . El marcador de terminación se ignora con los espacios iniciales, las pestañas, etc .:

print <<< END Content... Content.... END; # ↑ terminator isn''t exactly at the line start

Por lo tanto, el analizador asume que la cadena HEREDOC continúa hasta el final del archivo (por lo tanto, "$ inesperado final"). Casi todos los IDE y los editores de resaltado de sintaxis lo harán obvio o lo advertirán.

Comillas escapadas

Si lo usas /en una cadena, tiene un significado especial. Esto se denomina " carácter de escape " y normalmente le dice al analizador que tome el siguiente carácter literalmente.

Ejemplo: echo ''Jim said /'Hello/''';se imprimiráJim said ''hello''

Si se escapa de la cita de cierre de una cadena, la cita de cierre se tomará literalmente y no según lo previsto, es decir, como una cita imprimible como parte de la cadena y no la cerrará. Esto se mostrará como un error de análisis comúnmente después de abrir la siguiente cadena o al final de la secuencia de comandos.

Error muy común al especificar rutas en Windows: "C:/xampp/htdocs/"es incorrecto. Es necesario "C://xampp//htdocs//".

Sintaxis alternativa

Algo más raro puede ver este error de sintaxis cuando se utiliza la sintaxis alternativa para bloques de declaración / código en las plantillas. El uso if:y else:incumplido y unaendif; por ejemplo.

Ver también:

Inesperado ''=''

Esto puede ser causado por tener caracteres no válidos en un nombre de variable. Los nombres de las variables deben seguir estas reglas:

Los nombres de variables siguen las mismas reglas que otras etiquetas en PHP. Un nombre de variable válido comienza con una letra o un guión bajo, seguido de cualquier número de letras, números o guiones bajos. Como expresión regular, se expresaría así: ''[a-zA-Z_ / x7f- / xff] [a-zA-Z0-9_ / x7f- / xff] *''

Inesperado ''?''

Si intenta utilizar el operador de unión nula ??en una versión de PHP anterior a PHP 7, obtendrá este error.

<?= $a ?? 2; // works in PHP 7+ <?= (!empty($a)) ? $a : 2; // All versions of PHP

Inesperado ''continuar'' (T_CONTINUAR)

continuees una declaración (como para, o si) y debe aparecer independiente. No se puede utilizar como parte de una expresión. En parte porque continuar no devuelve un valor, pero en una expresión, cada subexpresión debe dar como resultado algún valor, de modo que la expresión general dé como resultado un valor. Esa es la diferencia entre una declaración y una expresión.

Eso significa continueque no se puede utilizar en una declaración ternaria o cualquier declaración que requiera un valor de retorno.

Inesperado ''break'' (T_BREAK)

Lo mismo vale para break; por supuesto.Tampoco es utilizable en el contexto de la expresión, sino una declaración estricta (en el mismo nivel foreacho un ifbloque).

Inesperado ''retorno'' (T_RETURN)

Ahora esto podría ser más sorprendente return, pero eso también es solo una declaración de nivel de bloque . Devuelve un valor (o NULL) al alcance / función superior, pero no se evalúa como expresión en sí misma. → Eso es: no tiene sentido hacerreturn(return(false);;

Inesperado T_LNUMBER

El token se T_LNUMBERrefiere a un "largo" / número.

  1. Nombres de variables no válidos

    En PHP, y en la mayoría de los otros lenguajes de programación, las variables no pueden comenzar con un número. El primer carácter debe ser alfabético o un subrayado.

    $1 // Bad $_1 // Good

    • A menudo surge el uso de preg_replace-placeholders "$1"en el contexto de PHP:

      # ↓ ⇓ ↓ preg_replace("/#(/w+)/e", strtopupper($1) )

      Donde el callback debería haber sido citado. (Ahora el /eindicador de expresión regular ha quedado en desuso. Pero a veces todavía se usa de forma incorrecta en las preg_replace_callbackfunciones)

    • La misma restricción de identificador se aplica a las propiedades del objeto , por cierto.

      ↓ $json->0->value

    • Mientras que el tokenizer / parser no permite un literal $1como nombre de variable, uno podría usar ${1}o ${"1"}. Que es una solución sintáctica para identificadores no estándar. (Lo mejor es considerarlo como una búsqueda de alcance local. Pero en general: ¡prefiero matrices simples para tales casos!)

    • Curiosamente, pero no muy recomendado, el analizador PHP permite los identificadores de Unicode; tal que $➊seria valido (A diferencia de un literal 1).

  2. Entrada de matriz perdida

    También puede ocurrir un largo inesperado para las declaraciones de matriz , cuando faltan ,comas:

    # ↓ ↓ $xy = array(1 2 3);

    O de la misma manera funcionan llamadas y declaraciones, y otras construcciones:

    • func(1, 2 3);
    • function xy($z 2);
    • for ($i=2 3<$z)

    Por lo general, hay uno ;o ,falta para separar listas o expresiones.

  3. HTML mal citado

    Y nuevamente, las cadenas mal citadas son una fuente frecuente de números extraviados:

    # ↓ ↓ echo "<td colspan="3">something bad</td>";

    Tales casos deben tratarse más o menos como errores T_STRING inesperados .

  4. Otros identificadores

    Ni las funciones, las clases ni los namespaces pueden nombrarse comenzando con un número:

    ↓ function 123shop() {

    Más o menos lo mismo que para los nombres de variables.

Inesperado T_IF
Inesperado T_FOREACH
Inesperado T_FOR
Inesperado T_WHILE
Inesperado T_DO
Inesperado T_ECHO

Control de construcciones tales como if, foreach, for, while, list, global, return, do, print, echopuede ser utilizado como declaraciones. Por lo general, residen en una línea por sí mismos.

  1. Punto y coma; donde estas

    Bastante universalmente, ¿te has perdido un punto y coma en la línea anterior si el analizador se queja de una declaración de control:

    ⇓ $x = myfunc() if (true) {

    Solución: mirar en la línea anterior; añadir punto y coma.

  2. Declaraciones de clase

    Otro lugar donde esto ocurre es en las declaraciones de clase . En la sección de clase solo puede listar las inicializaciones de propiedad y las secciones de método. Ningún código puede residir allí.

    class xyz { if (true) {} foreach ($var) {}

    Tales errores de sintaxis comúnmente se materializan para anidados incorrectamente {y }. En particular, cuando los bloques de código de función se cerraron demasiado pronto.

  3. Declaraciones en contexto de expresión

    La mayoría de las construcciones de lenguaje solo pueden usarse como declaraciones . No están destinados a ser colocados dentro de otras expresiones:

    ⇓ $var = array(1, 2, foreach($else as $_), 5, 6);

    Del mismo modo, no puedes usar un ifen cadenas, expresiones matemáticas o en otro lugar:

    ⇓ print "Oh, " . if (true) { "you!" } . " won''t work"; // Use a ternary condition here instead, when versed enough.

    Para incrustar ifcondiciones parecidas a una expresión específica, a menudo se desea utilizar una ?:evaluación ternaria .

    Lo mismo se aplica a for, while, global, echoy en menor medida list.

    ⇓ echo 123, echo 567, "huh?";

    Considerando que print()es un lenguaje incorporado que puede ser utilizado en el contexto de expresión. (Pero rara vez tiene sentido.)

  4. Palabras clave reservadas como identificadores

    Tampoco puede usar doni ifotras construcciones de lenguaje para funciones definidas por el usuario o nombres de clase. (Quizás en PHP7. Pero incluso entonces no sería aconsejable).

Inesperado T_IF
inesperado T_ELSEIF
inesperado T_ELSE
inesperado T_ENDIF

Los bloques de control condicional if, elseify elsesiguen una estructura simple. Cuando encuentra un error de sintaxis, es muy probable que solo sea un agrupamiento de nidos no válido → con {llaves que falten }, o uno demasiado.

  1. Falta {o }debido a la sangría incorrecta

    Los paréntesis de código no coincidentes son comunes a un código menos bien formateado, como:

    if((!($opt["uniQartz5.8"]!=$this->check58)) or (empty($_POST[''poree'']))) {if ($true) {echo"halp";} elseif((!$z)or%b){excSmthng(False,5.8)}elseif (False){

    Si su código se ve así, comience de nuevo! De lo contrario, es imposible de arreglar para usted o para cualquier otra persona. No tiene sentido mostrar esto en Internet para pedir ayuda.

    Solo podrá solucionarlo si puede seguir visualmente la estructura anidada y la relación de condicionales if / else y sus {bloques de código }. Usa tu IDE para ver si están todos emparejados.

    if (true) { if (false) { … } elseif ($whatever) { if ($something2) { … } else { … } } else { … } if (false) { // a second `if` tree … } else { … } } elseif (false) { … }

    Cualquier doble } }no solo cerrará una rama, sino una estructura de condición anterior. Por lo tanto, quédate con un estilo de codificación; no mezclar y combinar en árboles anidados si / else.

    Además de la consistencia aquí, también resulta útil evitar condiciones prolongadas. Utilice variables o funciones temporales para evitar ifexpresiones ilegibles .

  2. IF no se puede utilizar en expresiones

    Un error de recién llegado sorprendentemente frecuente es tratar de usar una ifdeclaración en una expresión, como una declaración de impresión:

    ⇓ echo "<a href=''" . if ($link == "example.org") { echo …

    Lo cual no es válido por supuesto.

    Puede usar un condicional ternario , pero tenga cuidado con los impactos de la legibilidad.

    echo "<a href=''" . ($link ? "http://yes" : "http://no") . "</a>";

    De lo contrario, rompa tales construcciones de salida: use múltiples ifs y echos .
    Mejor aún, use variables temporales y coloque sus condicionales antes:

    if ($link) { $href = "yes"; } else { $href = "no"; } echo "<a href=''$href''>Link</a>";

    Definir funciones o métodos para tales casos a menudo también tiene sentido.

    Los bloques de control no devuelven "resultados"

    Ahora esto es menos común, pero algunos codificadores incluso tratan de tratar ifcomo si pudiera devolver un resultado :

    $var = if ($x == $y) { "true" };

    Que es estructuralmente idéntico a usar ifdentro de una cadena de concatenación / expresión.

    • Pero las estructuras de control (if / foreach / while) no tienen un "resultado" .
    • La cadena literal "true" también sería una declaración nula.

    Tendrás que usar una asignación en el bloque de código :

    if ($x == $y) { $var = "true"; }

    Alternativamente, recurrir a una ?:comparación ternaria.

    Si en si

    No se puede anidarif dentro de una condición, ya sea:

    ⇓ if ($x == true and (if $y != false)) { ... }

    Lo que obviamente es redundante, porque el and(o or) ya permite las comparaciones en cadena.

  3. Punto y ;coma olvidado

    Una vez más: cada bloque de control debe ser una declaración. Si la pieza de código anterior no termina con un punto y coma, eso es un error de sintaxis garantizada:

    ⇓ $var = 1 + 2 + 3 if (true) { … }

    Por cierto, la última línea en un {…}bloque de código también necesita un punto y coma.

  4. Punto y coma demasiado temprano

    Ahora probablemente es un error culpar a un estilo de codificación particular, ya que esta trampa es demasiado fácil de pasar por alto:

    ⇓ if ($x == 5); { $y = 7; } else ← { $x = -1; }

    Lo que sucede más a menudo de lo que te imaginas.

    • Cuando termines la if ()expresión con; ella se ejecutará una declaración nula. El se ;convierte en un vacío {}propio!
    • Por lo {…}tanto, el bloque se separa de if, y siempre se ejecutaría.
    • Así que el elseya no tenía una relación con una ifconstrucción abierta , por lo que esto llevaría a un error de sintaxis T_ELSE inesperado.

    Lo que también explica una variación igualmente sutil de este error de sintaxis:

    if ($x) { x_is_true(); }; else { something_else(); };

    Cuando el ;bloque de código posterior {…}finaliza la ifconstrucción completa , se separa la elserama sintácticamente.

  5. No usar bloques de código

    Se permite sintácticamente omitir llaves {... }para bloques de código en if/ elseif/ elseramas. Lo que lamentablemente es un estilo de sintaxis muy común para los codificadores sin versión. (Bajo el supuesto falso, esto fue más rápido de escribir o escribir).

    Sin embargo, es muy probable que se tropiece con la sintaxis. Tarde o temprano, las declaraciones adicionales encontrarán su camino hacia las ramas if / else:

    if (true) $x = 5; elseif (false) $x = 6; $y = 7; ← else $z = 0;

    Sin embargo, para utilizar realmente los bloques de código, usted no tiene que escribir {... }como tales!

    Incluso los programadores experimentados evitan esta sintaxis implacable, o al menos la entienden como una excepción excepcional a la regla.

  6. Elseif / Elseif en el orden incorrecto

    Una cosa para recordar es el orden condicional , por supuesto.

    if ($a) { … } else { … } elseif ($b) { … } ↑

    Puedes tener tantos elseifs como quieras, pero elsetiene que ir el último . Así es como es.

  7. Declaraciones de clase

    Como se mencionó anteriormente , no puede tener declaraciones de control en una declaración de clase:

    class xyz { if (true) { function ($var) {} }

    O se olvidó una función de definición, o se cierra uno }demasiado temprano en estos casos.

  8. Inesperado T_ELSEIF / T_ELSE

    Al mezclar PHP y HTML, el cierre }de un if/elseifdebe estar en el mismo bloque de PHP <?php ?>que el siguiente elseif/else. Esto generará un error como cierre }para que las ifnecesidades formen parte de elseif:

    <?php if ($x) { ?> html <?php } ?> <?php elseif ($y) { ?> html <?php } ?>

    La forma correcta <?php } elseif:

    <?php if ($x) { ?> html <?php } elseif ($y) { ?> html <?php } ?>

    Esto es más o menos una variación de la sangría incorrecta, presumiblemente a menudo basada en intenciones de codificación erróneas.
    No se puede triturar otras declaraciones entre medio if y elseif/ elsefichas estructurales:

    if (true) { } echo "in between"; ← elseif (false) { } ?> text <?php ← else { }

    O bien, solo puede ocurrir en {…}bloques de código, no entre tokens de estructura de control.

    • Esto no tendría sentido de todos modos. No es que haya un estado "indefinido" cuando PHP salta ify se elseramifica.
    • Tendrá que decidir dónde pertenecen las declaraciones impresas o si deben repetirse en ambas sucursales.

    Tampoco puede separar un if / else entre diferentes estructuras de control:

    foreach ($array as $i) { if ($i) { … } } else { … }

    No hay relación sintáctica entre el ify else. El foreachámbito léxico termina en }, por lo que no tiene sentido que la ifestructura continúe.

  9. T_ENDIF

    Si un T_ENDIF inesperada se quejó de, usted está utilizando el estilo de sintaxis alternativa if:⋯ elseif:⋯ else:⋯endif; . Lo que realmente debería pensar dos veces.

    • Un error común es confundir los dos puntos inquietantemente similares :para un ;punto y coma . (Cubierto en "punto y coma demasiado temprano")

    • Como la sangría es más difícil de rastrear en los archivos de plantilla, más cuando se utiliza la sintaxis alternativa, es plausible endif;que no coincida con ninguna if:.

    • El uso } endif;es un doble if terminador.

    Mientras que un "final de $ inesperado" suele ser el precio de una }llave de cierre cerrada olvidada .

  10. Asignación vs. comparación

    Por lo tanto, esto no es un error de sintaxis, pero vale la pena mencionar en este contexto:

    ⇓ if ($x = true) { } else { do_false(); }

    Eso no es un ==/ ===comparación, sino una =asignación . Esto es bastante sutil, y llevará fácilmente a algunos usuarios a editar bloques enteros de condiciones sin poder hacer nada. Tenga cuidado con las asignaciones no intencionadas primero, siempre que experimente una falla / mal comportamiento lógico.

T_IS_EQUAL inesperada
T_IS_GREATER_OR_EQUAL inesperada
T_IS_IDENTICAL inesperada
T_IS_NOT_EQUAL inesperada
T_IS_NOT_IDENTICAL inesperada
T_IS_SMALLER_OR_EQUAL inesperada
inesperada <
inesperada>

Los operadores de comparación, como ==, >=, ===, !=, <>, !==y <=o <y >sobre todo deben utilizarse solo en las expresiones, tales como ifexpresiones. Si el analizador se queja de ellos, a menudo significa un emparejamiento incorrecto o ( )parens no coincidentes a su alrededor.

  1. Agrupación parens

    En particular para las ifdeclaraciones con comparaciones múltiples, debe tener cuidado de contar correctamente el paréntesis de apertura y cierre :

    ⇓ if (($foo < 7) && $bar) > 5 || $baz < 9) { ... } ↑

    Aquí la ifcondición aquí ya fue terminada por el)

    Una vez que las comparaciones se vuelven lo suficientemente complejas, a menudo ayuda dividirlas en ifconstrucciones múltiples y anidadas .

  2. isset () aplastado con la comparación

    Un recién llegado común es pitfal está tratando de combinar isset()o empty()con comparaciones:

    ⇓ if (empty($_POST["var"] == 1)) {

    O incluso:

    ⇓ if (isset($variable !== "value")) {

    Esto no tiene sentido para PHP, ya que issety emptyson construcciones del lenguaje que sólo aceptan los nombres de variables. Tampoco tiene sentido comparar el resultado, porque la salida es solo / ya es un valor booleano.

  3. Confundir >=mayor o igual con el =>operador de matriz

    Ambos operadores se ven algo similares, por lo que a veces se confunden:

    ⇓ if ($var => 5) { ... }

    Solo necesita recordar que este operador de comparación se llama " mayor o igual " para hacerlo bien.

    Ver también: Estructura de sentencias en PHP.

  4. Nada para comparar

    Tampoco puede combinar dos comparaciones si pertenecen al mismo nombre de variable:

    ⇓ if ($xyz > 5 and < 100)

    PHP no puede deducir que quisiste comparar la variable inicial nuevamente. Las expresiones generalmente se emparejan de acuerdo con la precedencia del operador , por lo que para el momento en que <se vea, solo quedará un resultado booleano de la variable original.

    Ver también: T_IS_SMALLER_OR_EQUAL inesperado

  5. Cadenas de comparacion

    No se puede comparar con una variable con una fila de operadores:

    ⇓ $reult = (5 < $x < 10);

    Esto tiene que ser dividido en dos comparaciones, cada una en contra $x.

    Esto es en realidad más un caso de expresiones en la lista negra (debido a la asociatividad del operador equivalente). Es sintácticamente válido en algunos lenguajes de estilo C, pero PHP tampoco lo interpretaría como una cadena de comparación esperada.

  6. Inesperado >
    inesperado<

    Los operadores mayor >o menor que <no tienen un T_XXXnombre de tokenizador personalizado . Y si bien pueden estar fuera de lugar como todos los demás, es más frecuente que el analizador se queje de ellos por las cadenas mal citadas y el HTML triturado:

    ⇓ print "<a href=''z">Hello</a>"; ↑

    Esto equivale a una cadena que "<a href=''z"se compara >con una constante literal Helloy luego otra <comparación. O al menos así lo ve PHP. La causa real y el error de sintaxis fue la "terminación prematura de la cadena .

    Tampoco es posible anidar las etiquetas de inicio de PHP:

    <?php echo <?php my_func(); ?> ↑

Ver también:

¿Cuáles son los errores de sintaxis?

PHP pertenece a los imperative programación imperative y C-style Tiene reglas gramaticales rígidas, de las que no puede recuperarse cuando encuentra símbolos o identificadores mal colocados. No puede adivinar sus intenciones de codificación.

Los consejos más importantes

Hay algunas precauciones básicas que siempre puedes tomar:

  • Use la sangría de código adecuada, o adopte cualquier estilo de codificación elevado. La legibilidad previene las irregularidades.

  • Utilice un IDE o editor para PHP con resaltado de sintaxis . Lo que también ayuda con paréntesis / equilibrio de brackets.

  • Lea la referencia del lenguaje y los ejemplos en el manual. Dos veces, llegar a ser algo competente.

Cómo interpretar los errores del analizador

Un mensaje de error de sintaxis típico lee:

Error de análisis: error de sintaxis, T_STRING inesperado, esperando '' ; '' en file.php en la línea 217

Lo que enumera la posible ubicación de un error de sintaxis. Ver el nombre del archivo mencionado y el número de línea .

Un apodo como T_STRING explica qué símbolo no pudo procesar finalmente el analizador / tokenizador. Sin embargo, esto no es necesariamente la causa del error de sintaxis.

También es importante mirar las líneas de código anteriores . A menudo, los errores de sintaxis son solo percances que ocurrieron antes. El número de la línea de error es justo donde el analizador se dio por vencido para procesarlo todo.

Resolviendo errores de sintaxis.

Hay muchos enfoques para reducir y corregir los problemas de sintaxis.

  • Abra el archivo fuente mencionado. Mira la línea de código mencionada.

    • Para cadenas fuera de control y operadores fuera de lugar, aquí es donde se encuentra el culpable.

    • Lee la línea de izquierda a derecha e imagina lo que hace cada símbolo.

  • Más regularmente, también hay que mirar las líneas anteriores .

    • En particular, falta ; faltan puntos y comas en los finales de línea / declaración. (Al menos desde el punto de vista estilístico.)

    • Si { bloques de código } están cerrados o anidados de forma incorrecta, es posible que deba investigar aún más el código fuente. Utilice la sangría de código adecuada para simplificar eso.

  • ¡Mira la coloración de la sintaxis !

    • Cadenas y variables y constantes deben tener diferentes colores.

    • Operadores +-*/. Debe ser teñido distinto también. De lo contrario, podrían estar en el contexto equivocado.

    • Si ve que la colorización de las cuerdas se extiende demasiado lejos o demasiado corta, entonces ha encontrado un cierre o '' marcador de cadena no escapado o faltante " .

    • Tener dos caracteres de puntuación del mismo color uno al lado del otro también puede significar problemas. Por lo general, los operadores están solos si no son ++ , -- , o paréntesis después de un operador. Dos cadenas / identificadores que se siguen directamente son incorrectos en la mayoría de los contextos.

  • El espacio en blanco es tu amigo . Sigue cualquier estilo de codificación.

  • Romper las largas colas temporalmente.

    • Puede agregar libremente nuevas líneas entre operadores o constantes y cadenas. El analizador luego concretará el número de línea para los errores de análisis. En lugar de mirar el código muy largo, puede aislar el símbolo de sintaxis perdido o extraviado.

    • Divida las declaraciones if complejas en distintas o anidadas if condiciones.

    • En lugar de largas fórmulas matemáticas o cadenas lógicas, use variables temporales para simplificar el código. (Más legible = menos errores.)

    • Añadir nuevas líneas entre:

      1. El código que puede identificar fácilmente como correcto,
      2. Las partes de las que no estás seguro,
      3. Y las líneas de las que se queja el analizador.

      La partición de bloques de código largos realmente ayuda a localizar el origen de los errores de sintaxis.

  • Comenta el código ofensivo.

    • Si no puede aislar la fuente del problema, comience a comentar (y, por lo tanto, eliminar) los bloques de código.

    • Tan pronto como eliminó el error de análisis, ha encontrado la fuente del problema. Mira más de cerca allí.

    • A veces desea eliminar temporalmente los bloques de función / método completos. (En caso de llaves no coincidentes y código incorrectamente sangrado).

    • Cuando no pueda resolver el problema de sintaxis, intente volver a escribir las secciones comentadas desde cero .

  • Como recién llegado, evita algunas de las construcciones de sintaxis confusas.

    • El ternario ? : ? : condición del operador puede compactar el código y es de hecho útil. Pero no ayuda a la legibilidad en todos los casos. Prefiero las declaraciones simples if sin revisión.

    • La sintaxis alternativa de PHP ( if: / elseif: / endif; ) es común para las plantillas, pero podría decirse que es menos fácil de seguir que los bloques normales de { código } .

  • Los errores más frecuentes de los recién llegados son:

    • Falta de punto ; coma ; para las declaraciones / líneas de terminación.

    • Las comillas de cadena no coinciden para " o '' y las comillas sin escapar dentro.

    • Operadores olvidados, en particular para la cadena . concatenación.

    • Desequilibrado ( paréntesis ) . Cuéntalos en la línea reportada. ¿Hay un número igual de ellos?

  • No olvide que resolver un problema de sintaxis puede descubrir el siguiente.

    • Si hace que un problema desaparezca, pero otro surge en algún código a continuación, la mayoría está en el camino correcto.

    • Si después de editar un nuevo error de sintaxis aparece en la misma línea, entonces su intento de cambio posiblemente fue un fracaso. (Aunque no siempre).

  • Restaure una copia de seguridad del código que funcionaba anteriormente, si no puede arreglarlo.

    • Adoptar un sistema de versiones de código fuente. Siempre se puede ver una diff de la diff rota y la última versión en funcionamiento. Lo que podría ser esclarecedor de cuál es el problema de la sintaxis.

  • Caracteres de Unicode perdidos invisibles : en algunos casos, necesita usar un editor de hexadecimal o un editor / visor diferente en su fuente. Algunos problemas no se pueden encontrar simplemente mirando su código.

    • Pruebe grep --color -P -n "/[/x80-/xFF/]" file.php como la primera medida para encontrar símbolos que no sean ASCII.

    • En particular, las listas de materiales, los espacios de ancho cero o los espacios sin interrupciones, y las comillas inteligentes pueden encontrar su camino en el código fuente.

  • Tenga cuidado de qué tipo de saltos de línea se guardan en archivos.

    • PHP solo respeta las líneas nuevas, no los retornos de carro.

    • Lo que ocasionalmente es un problema para los usuarios de MacOS (incluso en OS X para editores mal configurados).

    • A menudo solo surge como un problema cuando se utilizan los comentarios // o # una sola línea. /*...*/ comentarios de /*...*/ rara vez perturban el analizador cuando se ignoran los saltos de línea.

  • Si su error de sintaxis no se transmite a través de la web : Sucede que tiene un error de sintaxis en su máquina. Pero publicar el mismo archivo en línea ya no lo muestra. Lo que solo puede significar una de dos cosas:

    • Estás mirando el archivo equivocado!

    • O su código contenía Unicode callejero invisible (ver arriba). Puede descubrirlo fácilmente: simplemente copie su código desde el formulario web a su editor de texto.

  • Comprueba tu versión de PHP . No todas las construcciones de sintaxis están disponibles en todos los servidores.

  • No utilice las palabras clave reservadas de PHP como identificadores para funciones / métodos, clases o constantes.

  • Prueba y error es su último recurso.

Si todo lo demás falla, siempre puedes buscar en Google tu mensaje de error. Los símbolos de sintaxis no son tan fáciles de buscar (aunque en sí está indexado por SymbolHound ). Por lo tanto, puede tomar mirar unas cuantas páginas más antes de encontrar algo relevante.

Otras guías:

Pantalla blanca de la muerte

Si su sitio web está en blanco, la causa suele ser un error de sintaxis. Habilitar su pantalla con:

  • error_reporting = E_ALL
  • display_errors = 1

En su php.ini general, oa través de .htaccess para mod_php, o incluso .user.ini con configuraciones FastCGI.

Habilitarlo dentro del script roto es demasiado tarde porque PHP ni siquiera puede interpretar / ejecutar la primera línea. Una solución rápida es crear un script de envoltura, digamos test.php :

<?php error_reporting(E_ALL); ini_set("display_errors", 1); include("./broken-script.php");

Luego invoque el código que falla accediendo a este script de envoltura.

También ayuda a habilitar el error_log de PHP y ver el error.log su servidor web cuando un script falla con las respuestas HTTP 500.

Creo que este tema está totalmente sobreexplotado o demasiado complicado. Usar un IDE es LA manera de evitar completamente cualquier error de sintaxis. Incluso diría que trabajar sin un IDE es poco profesional. ¿Por qué? Porque los IDE modernos verifican tu sintaxis después de cada carácter que escribes. Cuando codifica y toda su línea se pone roja, y un gran aviso de advertencia le muestra el tipo exacto y la posición exacta del error de sintaxis, entonces no hay absolutamente ninguna necesidad de buscar otra solución.

El uso de un IDE de comprobación de sintaxis significa:

De hecho, nunca volverá a encontrarse con errores de sintaxis, simplemente porque los ve correctamente a medida que escribe. Seriamente.

Excelentes IDE con comprobación de sintaxis (todos ellos están disponibles para Linux, Windows y Mac):

  1. NetBeans [gratis]
  2. PHPStorm [$ 199 USD]
  3. Eclipse con PHP Plugin [gratis]
  4. Sublime [$ 80 USD] (principalmente un editor de texto, pero ampliable con complementos, como PHP Syntax Parser )