El plegado de código o texto , o menos comúnmente holofraseo , [1] es una característica de algunas interfaces gráficas de usuario que permite al usuario ocultar ("doblar") o mostrar ("desplegar") selectivamente partes de un documento. Esto permite al usuario administrar grandes cantidades de texto mientras ve solo aquellas subsecciones que son de interés actualmente. Normalmente se utiliza con documentos que tienen una estructura de árbol natural que consta de elementos anidados. Otros nombres para estas funciones incluyen expandir y contraer , ocultar código y delinear . En Microsoft Word , la función se llama "esquema plegable".
Muchas interfaces de usuario proporcionan widgets de divulgación para plegar código en una barra lateral, indicados, por ejemplo, mediante un triángulo que apunta hacia los lados (si está contraído) o hacia abajo (si está expandido), o mediante un [-]
cuadro para texto contraíble (expandido) y un [+]
cuadro para texto expandible ( colapsado) texto.
El plegado de código se encuentra en editores de texto , editores de código fuente e IDE . La estructura de plegado suele seguir el árbol de sintaxis del programa definido por el lenguaje informático . También puede definirse mediante niveles de sangría o especificarse explícitamente mediante un marcador dentro de 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 el texto normal, donde los elementos anidados constan de párrafos, secciones o niveles de esquema . Los programas que ofrecen esto incluyen editores plegables , esquematizadores 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 ejemplo más antiguo conocido de plegado de código en un editor se encuentra en NLS . [3] Probablemente el primer editor plegable ampliamente disponible fue el editor Structured Programming Facility (SPF) de 1974 para mainframes IBM 370 , que podía ocultar líneas según 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 la Instalación de productividad del sistema interactivo ( ISPF ).
El plegado de código tiene varios patrones de uso, principalmente organizando código u ocultando información menos útil para que uno pueda concentrarse en información más importante. Siguen patrones comunes. [5]
Básicamente, las aplicaciones utilizan el plegado de código para delinear el código fuente, colapsando cada bloque en una sola línea. Pueden ser solo bloques de nivel superior como funciones y clases, bloques anidados como funciones y métodos anidados, o todos los bloques, en particular bloques de flujo de control. Esto permite obtener una descripción general del código, navegarlo 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, para 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 oscurecer el punto principal. Además, el código sustantivo puede perderse en el texto estándar.
Por ejemplo, en Java, un único campo privado con un captador y un definidor requiere al menos 3 líneas, si cada una está en una línea separada:
nombre de cadena privada = nulo ; cadena pública getName () { nombre de retorno ; } public void setName ( nombre de cadena ) { this . nombre = 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):
nombre de cadena privada = nulo ; cadena pública getName () { nombre de retorno ; } public void setName ( nombre de cadena ) { this . nombre = nombre ; }
La documentación con Javadoc amplía esto a 20 líneas:
/** * Propiedad <código>nombre</código> legible/escribible. */ nombre de cadena privada = nulo ; /** * Getter para la propiedad <code>name</code> */ public String getName () { return nombre ; } /** * Establecedor de la propiedad <code>nombre</code>. * @param nombre */ public void setName ( nombre de cadena ) { 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 todos los campos de rutina están plegados, pero los campos no rutinarios (donde getter o setter no solo devuelven o asignan un campo privado) no están plegados, resulta más fácil ver el código sustancial.
Los metadatos pueden ser extensos y, por lo general, son menos importantes que los datos que describen. Colapsar metadatos permite centrarse principalmente en los datos, no en los metadatos. Por ejemplo, una larga lista de atributos en C# se puede contraer manualmente de la siguiente manera: [6]
Atributos de #región [Navegable(falso)] [Propiedad Mergable(falso)] [Valor predeterminado(nulo)] [Modo de persistencia(Modo de persistencia.InnerProperty)] [TemplateContainer(tipo de(Mi tipo))] [TemplateInstance(TemplateInstance.Single)] #endregion ITemplate pública Plantilla de contenido { get ; colocar ; }
El código resultante se muestra como:
Atributos public ITemplate ContentTemplate { get ; colocar ; }
Los comentarios son una forma de metadatos legibles por humanos y los comentarios extensos pueden interrumpir el flujo de código. Este puede ser el caso de un comentario largo 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 largos, pero mostrarlos sólo cuando sea necesario. En los casos en los que un comentario largo tiene una sola línea de resumen, como cadenas de documentos 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 consta de bloques de código anidados, y los bloques de código largos (como declaraciones de cambio largas) pueden oscurecer la estructura general. El plegado de código permite ver la estructura general y expandirse 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 programación estructurada, generalmente se adquiere un recurso, seguido de un bloque de código que utiliza el recurso y se termina liberando el recurso. El emparejamiento de adquisición/liberación es difícil de ver si hay un bloque largo de código en el medio, pero es fácil de ver si el bloque intermedio está plegado. De manera similar, en código condicional como if...then...else
, los bloques secundarios pueden estar lejos de la declaración de condición.
Los grupos plegables se pueden utilizar 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 una clase en grupos asociados) o implícitamente, como agrupando automáticamente a los miembros de la clase por nivel de acceso.
El código heredado, o cualquier código que un desarrollador no desee ver o cambiar en un momento determinado, se puede plegar para que los programadores puedan concentrarse en el código que se está considerando.
Para admitir el plegado de código, el editor de texto debe proporcionar un mecanismo para identificar "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 aumentar.
Hay varios mecanismos, divididos a grandes rasgos en automáticos y manuales. ¿Requieren alguna especificación por parte del programador? Los puntos de plegado suelen determinarse con uno o más de los siguientes mecanismos. Cada uno de estos tiene sus propias ventajas y dificultades, y esencialmente depende de los desarrolladores que crean el software de edición de texto decidir cuál implementar. Los editores de texto que brindan soporte para múltiples mecanismos de plegado generalmente permiten al usuario elegir cuál es el más apropiado 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 regiones de plegado específicas. Los puntos de plegado basados en sintaxis generalmente se definen 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 generalmente se especifican mediante la posición y secuencia de espacios en blanco que no se imprimen, 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 fuera de juego , por lo que la estructura concuerda en gran medida con la sangría. Los ejemplos incluyen Python y archivos de texto que requieren 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 mediante 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ía, 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 }}}
finalizarla.
Otro token notable son #region
(directivas C#), respectivamente #Region
(directivas Visual Basic), utilizadas en Microsoft Visual Studio Code Editor . Se tratan sintácticamente como directivas del compilador , aunque no afectan la compilación.
Como método manual, el plegado basado en tokens permite discreción al agrupar código 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 dentro de banda, siendo los tokens plegables 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 fricciones y cargas de mantenimiento.
El plegado especificado por el usuario le permite doblar secciones de texto usando un método de selección genérico, pero sin cambiar el código fuente (fuera de banda), sino que se especifica solo en el editor. Por ejemplo, un programador puede seleccionar algunas líneas de texto y especificar que deben doblarse. El texto plegado puede ser anónimo o tener un nombre, y puede conservarse durante 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 fichas plegables ( {{{ ... }}}
):
Título 1 {{{ Cuerpo }}} Título 2 {{{ Cuerpo }}} Título 3 {{{ Cuerpo }}}
Cuando se carga en un editor de plegado, se mostrará la estructura del esquema:
Título 1 {{{... Título 2 {{{... Título 3 {{{...
Por lo general, al hacer clic en las {{{
marcas aparece el texto del cuerpo apropiado.
Uno de los primeros editores plegables 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 se puede plegar y reemplazar por una línea de nombre (que a su vez puede ser parte de un bloque que luego se puede plegar).
Alrededor de 1983 apareció un editor plegable en el IDE de occam , que se llamó 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 tenía varios editores de código fuente que "doblaban" porciones de código mediante " triángulos de divulgación ". El producto Frontier de UserLand Software es un entorno de scripting que tiene esta capacidad. [9]
Muchos editores de texto modernos proporcionan el plegado, 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-display
función en Emacs para ocultar líneas según el nivel de sangría, como se sugiere en la nota sobre plegado del código universal.senator-fold-tag
comando para sintaxis soportadas por semantic (un componente de CEDET), así como por el modo doc para comentarios JavaDoc o Doxygen , por TeX-fold-mode , sgml-fold-element
comando, nxml- biblioteca outln en los modos específicos del idioma correspondiente y posiblemente en otros modos para sintaxis particulares. A veces, el modo menor estándar de esquema simple se utiliza para simular el plegado basado en sintaxis, cf. el uso del mismo en el código fuente de Emacs Lisp con sangría adecuada, el uso del mismo (ver cerca del final de la página) para HTML con sangría adecuada. Varios mecanismos de plegado están unificados por la interfaz fold-dwim . Véase también CategoryHideStuff.hide-region-hide
.set_selective_display
función se puede utilizar para ocultar líneas con sangría más allá de una cantidad especificada.{{cite book}}
: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace ){{cite web}}
: Mantenimiento CS1: posdata ( enlace )fe
editor.