El plegado de código o texto , o con menos frecuencia, el holofrasteo , [1] es una característica de algunas interfaces gráficas de usuario que permite al usuario ocultar ("plegar") o mostrar ("desplegar") de forma selectiva partes de un documento. Esto permite al usuario gestionar grandes cantidades de texto mientras ve solo aquellas subsecciones que son de interés en ese momento. Se utiliza normalmente con documentos que tienen una estructura de árbol natural que consta de elementos anidados. Otros nombres para estas características incluyen expandir y contraer , ocultación de código y esquematización . En Microsoft Word , la característica se llama "esquema colapsable".
Muchas interfaces de usuario proporcionan widgets de divulgación para plegar código en una barra lateral, indicados, por ejemplo, por un triángulo que apunta hacia los lados (si está colapsado) o hacia abajo (si está expandido), o por un [-]cuadro para texto colapsable (expandido) y un [+]cuadro para texto expandible (contraído).
El plegado de código se encuentra en editores de texto , editores de código fuente e IDE . La estructura de plegado generalmente sigue el árbol de sintaxis del programa definido por el lenguaje de computadora . También puede definirse por niveles de sangría o especificarse explícitamente utilizando un marcador en banda (guardado como parte del código fuente) o fuera de banda.
El plegado de texto es una función similar que se utiliza en textos ordinarios, donde los elementos anidados consisten en párrafos, secciones o niveles de esquema . Entre los programas que ofrecen esta función se incluyen editores de plegado , programadores de esquemas y algunos procesadores de texto .
El plegado de datos se encuentra en algunos editores hexadecimales y se utiliza para estructurar un archivo binario u ocultar secciones de datos inaccesibles. [2]
El plegado también se utiliza frecuentemente en la comparación de datos , para seleccionar una versión u otra, o sólo las diferencias.
El primer ejemplo conocido de plegado de código en un editor se encuentra en NLS . [3] Probablemente el primer editor de plegado ampliamente disponible fue el editor Structured Programming Facility (SPF) de 1974 para mainframes IBM 370 , que podía ocultar líneas en función de su sangría. Se mostraba en terminales 3270 con mapas de caracteres. [4] Fue muy útil para lenguajes prolijos como COBOL . Evolucionó hasta convertirse en Interactive System Productivity Facility ( ISPF ).
El plegado de código tiene varios patrones de uso, principalmente para organizar el código u ocultar información menos útil para que uno pueda concentrarse en información más importante. A continuación se presentan algunos patrones comunes. [5]
Básicamente, las aplicaciones utilizan el plegado de código para delinear el código fuente, reduciendo cada bloque a una sola línea. Esto puede ser solo bloques de nivel superior como funciones y clases, bloques anidados como funciones y métodos anidados, o todos los bloques, en particular los bloques de flujo de control. Esto permite obtener una descripción general del código, navegar y reorganizarlo fácilmente, y profundizar en más detalles según sea necesario, sin distraerse con otro código. En cuanto a la visualización, esto permite ver rápidamente una lista de todas las funciones (sin sus cuerpos), mientras que en cuanto a la navegación, esto reemplaza la paginación extensa de funciones largas (o la búsqueda del objetivo) con ir directamente a la siguiente función.
Algunos lenguajes o bibliotecas requieren un código repetitivo extenso . Esto da como resultado un código extremadamente largo, que puede ocultar el punto principal. Además, el código sustancial puede perderse en el código repetitivo.
Por ejemplo, en Java, un solo campo privado con un captador y un definidor requiere al menos 3 líneas, si cada una está en una línea separada:
cadena privada nombre = null ; cadena pública getName ( ) { return nombre ; } cadena pública void setName ( cadena nombre ) { this.name = nombre ; } Esto se expande a 10 líneas con saltos de línea de función convencionales y espaciado entre funciones (incluida la nueva línea final):
cadena privada nombre = null ; public String getName () { devolver nombre ; } public void setName ( String nombre ) { this.name = nombre ; } La documentación con Javadoc amplía esto a 20 líneas:
/** * Propiedad <code>nombre</code> legible/escribible. */ private String nombre = null ; /** * Getter para la propiedad <code>nombre</code> */ public String getName () { return nombre ; } /** * Establecedor para la propiedad <code>nombre</code>. * @param nombre */ public void setName ( String nombre ) { this . nombre = nombre ; } Si hay muchos campos de este tipo, el resultado puede ser fácilmente cientos de líneas de código con muy poco contenido "interesante"; el plegado de código puede reducir esto a una sola línea por campo, o incluso a una sola línea para todos los campos. Además, si se pliegan todos los campos rutinarios, pero no se pliegan los campos no rutinarios (donde el getter o setter no solo devuelve o asigna un campo privado), resulta más fácil ver el código sustantivo.
Los metadatos pueden ser extensos y, por lo general, son menos importantes que los datos que describen. La contracción de metadatos permite centrarse principalmente en los datos, no en los metadatos. Por ejemplo, una lista larga de atributos en C# se puede contracción manual de la siguiente manera: [6]
#region Atributos [Explorable(falso)] [PropiedadCombinable(falso)] [ValorPredeterminado(nulo)] [ModoPersistencia(PersistenceMode.InnerProperty)] [ContenedorTemplate(tipode(MiTipo))] [InstanciaTemplate(InstanciaTemplate.Single)] #endregion public ITemplate ContentTemplate { obtener ; establecer ; } El código resultante se muestra como:
Atributos públicos ITemplate ContentTemplate { obtener ; establecer ; } Los comentarios son una forma de metadatos legibles para humanos, y los comentarios extensos pueden interrumpir el flujo del código. Este puede ser el caso de un comentario extenso para una sección corta de código, como un párrafo para explicar una línea, o comentarios para generadores de documentación , como Javadoc o Documentación XML. El plegado de código permite tener comentarios extensos, pero mostrarlos solo cuando sea necesario. En los casos en los que un comentario extenso tiene una sola línea de resumen, como las cadenas de documentación de Python, el resumen aún se puede mostrar cuando la sección está contraída, lo que permite una vista resumida/detallada.
La programación estructurada consiste en bloques de código anidados, y los bloques largos de código (como las sentencias switch largas) pueden oscurecer la estructura general. El plegado de código permite ver la estructura general y expandirla a un nivel específico. Además, en algunos usos, particularmente en la programación estructurada estricta (salida de función única), hay patrones de código que son difíciles de ver cuando se mira el código expandido. Por ejemplo, en la gestión de recursos en la programación estructurada, generalmente se adquiere un recurso, seguido de un bloque de código que utiliza el recurso y se termina con la liberación del recurso. El emparejamiento adquisición/liberación es difícil de ver si hay un bloque largo de código en el medio, pero es fácil verlo si el bloque intermedio está plegado. De manera similar, en el código condicional como if...then...else, los bloques secundarios pueden estar lejos de la sentencia de condición.
Los grupos de pliegues se pueden usar para agrupar código, ya sea mediante agrupación explícita (similar a los bloques de comentarios que separan un módulo en secciones o miembros de clase en grupos asociados) o implícitamente, como agrupando automáticamente a los miembros de clase por nivel de acceso.
El código heredado (o cualquier código que un desarrollador no desea ver o cambiar en un momento dado) se puede eliminar para que los programadores puedan concentrarse en el código en cuestión.
Para permitir el plegado de código, el editor de texto debe proporcionar un mecanismo para identificar los "puntos de plegado" dentro de un archivo de texto. Algunos editores de texto proporcionan este mecanismo automáticamente, mientras que otros proporcionan valores predeterminados que el usuario puede anular o ampliar.
Existen varios mecanismos, que se dividen a grandes rasgos en automáticos y manuales. ¿Requieren alguna especificación por parte del programador? Los puntos de plegado se determinan normalmente con uno o más de los siguientes mecanismos. Cada uno de ellos tiene sus propias ventajas y dificultades, y es esencialmente responsabilidad de los desarrolladores que crean el software de edición de texto decidir cuál implementar. Los editores de texto que admiten varios mecanismos de plegado suelen permitir al usuario elegir cuál es el más adecuado para el archivo que se está editando.
Los puntos de plegado dependientes de la sintaxis son aquellos que dependen del contenido del archivo que se está editando para especificar dónde deben comenzar y terminar las regiones de plegado específicas. Los puntos de plegado basados en la sintaxis se definen típicamente en torno a cualquiera o todas las subcaracterísticas estándar del lenguaje de marcado o lenguaje de programación en uso. Estos son deseables debido a que son automáticos y concuerdan con la estructura del código, pero pueden requerir un trabajo significativo para implementarlos y tiempo para calcularlos al editar un archivo.
Los puntos de plegado basados en sangría se especifican generalmente por la posición y secuencia de espacios en blanco no imprimibles, como tabulaciones y espacios, dentro del texto. Esto se utiliza con mayor frecuencia como una forma simple de plegado basado en sintaxis, ya que la sangría casi siempre refleja el nivel de anidamiento en los estilos de sangría para lenguajes de programación estructurados.
Esta convención es particularmente adecuada para sintaxis que tienen una regla de fuera de línea , por lo que la estructura coincide en gran medida con la sangría. Algunos ejemplos incluyen Python y archivos de texto que requieren la sangría como regla por sí mismos. Sin embargo, incluso en estos casos, la estructura no coincide exactamente con la sangría, como en la continuación de línea , y por lo tanto se prefiere el plegado dependiente de la sintaxis.
Los puntos de plegado basados en tokens se especifican utilizando delimitadores especiales que no tienen otro propósito en el texto que identificar los límites de los puntos de plegado. Esta convención se puede comparar con los puntos de plegado basados en sangrías, donde se utilizan caracteres imprimibles en lugar de espacios en blanco. Los tokens delimitadores más comunes son {{{para comenzar la sección plegada y }}}para finalizarla.
Otro token notable son #regionlas directivas de C# o #Regionlas directivas de Visual Basic, que se utilizan en el Editor de código de Microsoft Visual Studio . Se tratan sintácticamente como directivas del compilador , aunque no afectan a la compilación.
Como método manual, el plegado basado en tokens permite agrupar el código con discreción según criterios arbitrarios, como "funciones relacionadas con una tarea determinada", que no se pueden inferir del análisis sintáctico.
El plegado basado en tokens requiere señalización en banda, y los tokens de plegado son esencialmente comentarios estructurados y, a diferencia de otros métodos, están presentes en el código fuente y son visibles para otros programadores. Esto permite compartirlos, pero también requiere su uso (o conservación) por parte de todos los programadores que trabajan en un archivo en particular, y puede causar fricción y carga de mantenimiento.
El plegado especificado por el usuario permite al usuario plegar secciones de texto utilizando un método de selección genérico, pero sin cambiar el código fuente (fuera de banda), sino que se especifica únicamente en el editor. Por ejemplo, un programador puede seleccionar algunas líneas de texto y especificar que deben plegarse. El texto plegado puede ser anónimo o tener nombre, y esto puede conservarse en las sesiones de edición o descartarse. A diferencia del plegado basado en tokens, esto no cambia el texto fuente; por lo tanto, no se comparte con otros editores del archivo y no es visible en el código.
El siguiente documento contiene tokens plegables ( {{{ ... }}}):
Título 1 {{{ Cuerpo }}} Título 2 {{{ Cuerpo }}} Título 3 {{{ Cuerpo }}}Al cargarlo en un editor plegable, se mostrará la estructura del esquema:
Título 1 {{{ ... Título 2 {{{ ... Título 3 {{{ ...Generalmente al hacer clic en las {{{marcas aparece el texto del cuerpo correspondiente.
Uno de los primeros editores de plegado fue STET , un editor escrito para el sistema operativo VM/CMS en 1977 por Mike Cowlishaw . STET es un editor de texto (para documentación, programas, etc.) que pliega archivos en base a bloques de líneas; cualquier bloque de líneas puede plegarse y reemplazarse por una línea de nombre (que a su vez puede ser parte de un bloque que luego puede plegarse).
Alrededor de 1983 apareció en el IDE de occam un editor plegable , llamado Inmos Transputer Development System (TDS) [7] , [8] El editor "f" (en la lista a continuación) es probablemente el legado más intacto de este trabajo .
Históricamente, la computadora Macintosh contaba con una serie de editores de código fuente que "plegaban" partes del código mediante " triángulos de apertura ". El producto Frontier de UserLand Software es un entorno de programación que tiene esta capacidad. [9]
Muchos editores de texto modernos ofrecen la posibilidad de plegar, y el plegado basado en sintaxis o semántica es ahora un componente de muchos entornos de desarrollo de software . Los editores incluyen:
set-selective-displayfunción en Emacs para ocultar líneas según el nivel de sangría, como se sugiere en la nota de plegado de código universal.senator-fold-tagcomando para sintaxis soportadas por semantic (un componente de CEDET), así como por doc-mode para comentarios de JavaDoc o Doxygen , por TeX-fold-mode , sgml-fold-elementcommand, nxml-outln library en los modos específicos del lenguaje correspondientes, y posiblemente en otros modos para sintaxis particulares. A veces, el modo menor outline simple estándar es usado para simular plegado basado en sintaxis, cf. el uso de este en código fuente de Emacs Lisp correctamente sangrado, el uso de este (ver cerca del final de la página) para HTML correctamente sangrado. Varios mecanismos de plegado son unificados por la interfaz fold-dwim . Ver también CategoryHideStuff.hide-region-hidecomando.set_selective_displayfunción se puede utilizar para ocultar líneas sangradas más allá de una cantidad especificada.{{cite book}}: CS1 maint: nombres numéricos: lista de autores ( enlace ){{cite web}}: Mantenimiento de CS1: postscript ( enlace )
feeditor.