Cierre de etiquetas END en los INCLUDE

Windgate · September 25, 2009, 08:12:25 PM

Hola amiguitos, quería sugerir una funcionalidad sencillita pero muy útil a nivel de compilador.

Resulta que muchas veces hacemos INCLUDE para añadir un fichero de código a nuestro programa en el que especificamos uno o más procesos (U otras cosas).

Ya sabemos que todos los procesos tienen un número de etiquetas de "apertura" como BEGIN o LOOP igual al de etiquetas de "cierre" END.

El caso es que si nos dejamos un END en uno de los ficheros de código que incluimos, el compilador no es capaz de detectar el error hasta que la cuenta de etiquetas de "apertura" y "cierre" no salen, esto es muchas veces en el BEGIN del programa principal... Y es ahí donde salta el error y tenemos que mirarnos los ficheros modificados hasta localizar ese maldito END

Yo sugiero que el compilador, al llegar a un fichero que se carga con INCLUDE, sea capaz de contar los ENDs dentro de ese fichero para poder predecir que el error se encuentra en él...

¿Qué os parece la idea? ¿Os excita?

PD: A mí no me sucede porque estoy curado de tener esos fallos, pero a algunos de mis alumnos a veces les pasa y es una tortura ayudarles a encontrar el error :P

DCelso · September 25, 2009, 10:30:24 PM

Yo, como truco, uso el bgdindent que hice en todos los archivos, si algún archivo no se indenta bien es que algo falla, asi que me voy a donde ha empezado a fallar y busco el error hasta que al indentar todo encuadra.

Windgate · September 25, 2009, 10:50:51 PM

¿Con indentar te refieres a "tabular" las líneas de código hacia la derecha cuando abres etiqueta (BEGIN, LOOP, etc) y hacia la izquierda cuando cierras con END? ¿O te refieres al hecho de contar etiquetas de apertura y cierre (END) para comprobar si falta/sobra algún END?

Sorry pero es que uso siempre un lenguaje muy muy basto para referirme a ciertas tareas de programación y lo de "indentar" me suena poco familar, yo nací en un pueblo y en mi juventud he comido cosas que harían vomitar a una cabra...

DCelso · September 25, 2009, 10:59:34 PM

Perdona, es un anglicismo, la palabra reconocida en la rae es Sangrado
http://es.wikipedia.org/wiki/Indentación
Yo hice un programilla para hacer esto, pero el propio fbmx también lo hace.

Yo, esta técnica la uso mucho a la hora de programar en c con eclipse, se que no es lo correcto pero gracias a ella gano velocidad porque programo sin preocuparme de si todo está bien alineado e incluso a veces en una misma sola línea, luego pulso control shift f y mágicamente todo el código se ordena y queda perfecto para ser entendido.
El bgdindent.exe que hice yo no es tan bueno, es decir, no separa instrucciones que estén en la misma línea, pero ayuda bastante.

SplinterGU · September 25, 2009, 11:50:40 PM

nop, eso no deberia hacerse, ya que un include puede ser una porcion de codigo... incluso puede ser el inicio de un codigo incluyendo un BEGIN y en otro include o en el llamador puede estar el end...

DCelso · September 26, 2009, 12:09:44 AM

Eso no parece muy práctico y complica su lectura, ¿No?

SplinterGU · September 26, 2009, 12:24:48 AM

no, para nada...

el include es "inserta este texto aca"... eso es un include...

Windgate · September 26, 2009, 01:22:07 AM

¿Entonces para el caso que yo hablo de "incluir" ficheros .prg en los que a priori estoy seguro que guardo declaraciones de procesos completos hay algo mejor que INCLUDE? Algo como import por ejemplo, que no pueda dar los problemas de los que hablo.

Comprendo la utilidad actual de INCLUDE y si es así no está "bien" mi sugerencia, pero creo que debería haber alguna forma de incluir teniendo en cuenta que el fichero incluido debe ser correcto en cuanto a apertura/cierre de etiquetas.

Drumpi · September 26, 2009, 01:28:16 AM

Yo he hecho eso que dice Splinter en mi motor tileado: hay una parte que la tengo que repetir en varios sitios porque hace una tarea concreta, y esta debe hacerse bajo unas determinadas condiciones, y dado que no existen subrutinas y crear funciones no me sirve porque trabajo escaso de CPU, prefiero ocupar unos cuantos bytes más en el DCB... y uso el include como si fuese la llamada a la funcion, y deja el código mucho más entendible.

Una ayuda para la apertura y cierre de etiquetas, además del sangrado, es poner el END justo despues de escribir la sentencia de apertura (por ejemplo, justo después de escribir el IF y sus condiciones) y luego escribir el código dentro.
Otra es poner después del END las barras // y dejar el comentario de lo que cierra:

while (i<35)
(codigo)

END //contador i, while o lo que mejor te lo recuerde

Windgate · September 26, 2009, 10:08:18 AM

Sí Drumpi, es lo que hago siempre, son ya muchos años programando y muchas horas seguidas buscando esa maldita etiqueta de cierre en el proyecto que hay que presentar al día siguiente >:(

La sugerencia no es por mí, es por mis pequeños alumnos, recuerdo mis primeros encuentros con la programación y no hay cosa que produzca más dolor moral al principio que el compilador dando un error a 300 líneas de donde se encuentra realmente... Y tú preguntándote por qué no es capaz de cerrar ese END que falta xD

Nosotros entendemos cómo funcionan estas cosas, pero recordad que también una vez fuimos jóvenes y virginales.

En conclusión, se me ocurre como sugerencia un WARNING que advierta que "pueden" faltar etiquetas de cierre en el fichero xxx.prg implicado...

Drumpi · September 27, 2009, 03:10:39 AM

Pero es que no sabes en cual de todos los archivos que forman el código está el error, es imposible saberlo. Sólo si en todos ellos cierras todo lo que abres podría ser, pero con que haya un sólo if que lo cierres en otro fichero distinto, ya no se puede localizar el error.

Windgate · September 27, 2009, 06:09:26 AM

Se puede localizar el error si para cada fichero por separado haces un conteo de etiquetas de apertura y cierre y determinas si falta/sobra alguna, de ahí se podría lanzar el WARNING indicando "xxx.prg might have a lost END tag" o algo así.

Drumpi · September 27, 2009, 11:41:10 PM

Podría, pero si se da que:

-xxx01.prg tiene un END de menos
-xxx02.prg tiene un END de más

¿Uno compensa al otro? ¿O es que has tenido DOS errores al programar? Podría dar el warning, pero no recuerdo ningún compilador que lo haga.

DCelso · September 28, 2009, 12:23:44 AM

A mi me gusta la idea de wingate. Una advertencia para decir que tal archivo no tiene todos los ends necesarios es muy buena ayuda, ya que en el caso que sea a posta lo sabrás (sabrás que te falta un end a posta porque está en otro archivo) y en el caso de que no lo sea podrías analizar simplemente este archivo para buscar el fallo.
En el caso que tu propones pues habría dos warnings uno en el archivo en el que le falta el end, y otro en el archivo en el que le sobra un end.

Windgate · September 28, 2009, 12:28:43 AM

Mi idea va orientada a poder "compilar" un fuente que por ejemplo sólo tenga una declaración de proceso... Y poder detectar si tiene errores.

En C por ejemplo si compilas un proyecto con varios fuentes es capaz de detectar un error de ese tipo e indicar cuál es el fuente donde falta la llave de cierre.

Cierto que INCLUDE no es lo que yo pensaba, y es "legal" que falten etiquetas de cierre... Pero me sigue pareciendo una utilidad interesante lo que propongo.

También apoyo lo de DCelso, pensad que hablo de un warning, es algo muy light.