Tema 4 Optimización y Documentación

¿Qué permite la documentación del código?. Facilitar su comprensión y mantenimiento. Aumentar la velocidad de ejecución. Ocultar errores. Reducir la complejidad del hardware.

¿Qué uso principal tienen los comentarios en el código?. Explicar el funcionamiento del código. Aumentar el rendimiento. Sustituir líneas de código. Identificar errores.

¿Qué se debe evitar al escribir comentarios?. Comentar métodos públicos. Comentar lo obvio. Usar lenguaje natural. Usar etiquetas estándar.

¿Qué pasa si se abusa de los comentarios?. Mejora la legibilidad. Puede indicar mal diseño. Optimiza el rendimiento. Reduce el tamaño del archivo.

¿Qué tipo de comentarios son recomendables?. De estilo libre. Concisos, claros y relevantes. En mayúsculas. Comentarios multilineales en exceso.

¿Qué estructura deben seguir los comentarios?. Cronológica. Explicativa y directa. Con nombres de usuario. Con fecha de compilación.

¿Cuál es uno de los errores más comunes al comentar código?. Comentar lo evidente. Usar siglas. Escribir en inglés. Especificar rutas de archivo.

¿Qué indican los comentarios innecesarios o en exceso?. Buen diseño. Código difícil de entender. Código modular. Pruebas automatizadas.

¿Qué alternativa a los comentarios puede mejorar la comprensión?. Nombrado claro de variables y métodos. Inserción de gráficos. Comprobación de errores. Comentarios en HTML.

¿Qué es preferible a escribir muchos comentarios?. Hacer el código más expresivo. Duplicar código. Eliminar clases. Refactorizar todo el sistema.

¿Qué se debe documentar en clases y métodos?. Solo el autor. Propósito, parámetros y valores de retorno. Velocidad de ejecución. La RAM consumida.

¿Qué debe evitarse en la documentación?. El uso de etiquetas. Información desactualizada. Nombres de funciones. Estructura modular.

¿Qué tipo de documentación se genera con herramientas específicas?. Documentación técnica estructurada. Comentarios de usuario. Diagramas UML. Manuales legales.

¿Qué lenguaje es comúnmente usado por herramientas como Javadoc?. HTML. Java. Python. XML.

¿Cuál de estas herramientas permite documentar código en Java?. DokuWiki. Javadoc. Notepad++. WinRAR.

¿Qué permite hacer Javadoc automáticamente?. Generar documentación en formato HTML. Optimizar el código. Validar sintaxis. Compilar proyectos.

¿Qué beneficio tiene documentar una clase?. Facilita el trabajo en equipo y el mantenimiento. Aumenta el tamaño del archivo. Reduce la calidad del software. Oculta errores del IDE.

¿Qué parte del código debe documentarse especialmente bien?. Clases y métodos públicos. Variables locales. Estructuras de control. Comentarios en consola.

¿Qué se debe evitar en los comentarios?. Redundancia y obviedad. Lenguaje técnico. Palabras en inglés. Comas y puntos.

¿Cuál es una característica de una buena documentación?. Ser muy extensa. Ser clara, precisa y actualizada. Usar solo etiquetas técnicas. Incluir todos los detalles internos del sistema.

¿Cuál es la finalidad principal de los comentarios en el código?. Ejecutar fragmentos de prueba. Facilitar la comprensión del funcionamiento del código. Aumentar la velocidad de ejecución. Reducir errores de compilación.

¿Qué tipo de comentarios deben evitarse?. Los que explican lo obvio. Los que están en inglés. Los que tienen etiquetas. Los que están al inicio del archivo.

¿Qué se considera un uso incorrecto de los comentarios?. Describir instrucciones evidentes. Comentar bloques complejos. Documentar métodos públicos. Anotar valores devueltos.

¿Qué puede reflejar un uso excesivo de comentarios?. Modularidad. Mal diseño del código. Buen estilo. Código optimizado.

¿Qué alternativa es preferible a un comentario explicando el código?. Usar nombres de variables y funciones claros y descriptivos. Aumentar la longitud de los comentarios. Añadir diagramas al código. Documentar en otro archivo.

¿Qué tipo de comentarios ayudan a entender estructuras complejas?. Comentarios específicos y bien colocados. Comentarios genéricos. Comentarios duplicados. Comentarios en otro idioma.

¿Dónde deben colocarse los comentarios en funciones o métodos?. Dentro del bloque return. Justo antes de su definición. Al final del código. Entre paréntesis.

¿Qué longitud deben tener los comentarios para ser eficaces?. Mínimo 5 líneas. Breves y concisos. Tan largos como sea posible. Deben incluir ejemplos detallados.

¿Qué mejora directamente la presencia de comentarios bien escritos?. La compilación del código. La legibilidad y mantenibilidad. La interfaz gráfica. El uso de memoria.

¿Qué debe evitar un comentario en cuanto a su contenido?. Ser técnico. Repetir el contenido exacto del código. Explicar las condiciones. Incluir fechas.

¿Por qué es mejor un buen nombre de función que un comentario?. Porque el código se explica por sí mismo. Porque ocupa menos espacio. Porque evita errores de compilación. Porque lo exige la normativa.

¿Qué tipo de mantenimiento facilita el uso de comentarios adecuados?. Preventivo. Correctivo y evolutivo. Predictivo. Externo.

¿Qué elemento del comentario permite estandarizar la documentación?. Código hash. Etiquetas como @param y @return. Comentarios en mayúsculas. Variables constantes.

¿Qué permite evitar la redundancia en los comentarios?. Escribir código claro y bien estructurado. Usar sinónimos. Escribir comentarios en otro archivo. Ocultar funciones.

¿Qué se recomienda sobre los comentarios en código limpio?. Usarlos solo cuando sean necesarios. Colocarlos en todos los bloques. Redactarlos en inglés técnico. Duplicarlos en cada clase.

¿Qué tipo de errores se asocian al uso inadecuado de comentarios?. De ejecución. De diseño y comprensión. De compilación. De sintaxis.

¿Qué función NO cumple un comentario?. Ejecutar instrucciones. Explicar algoritmos complejos. Documentar intenciones del programador. Guiar el mantenimiento.

¿Qué se considera un mal comentario?. Uno con lenguaje técnico. Uno que no aporta información nueva. Uno que define la función. Uno que describe parámetros.

¿Qué principio debe guiar la inclusión de comentarios?. Comentar solo cuando sea necesario. Comentar todo el código sin excepción. Comentar en bloques de 3 líneas. Comentar siempre en inglés.

¿Qué es más útil que comentar cada línea del código?. Escribir código autoexplicativo. Separar el código en archivos pequeños. Documentar en PDF. Usar iconos visuales.

¿Cuál es una alternativa válida al uso excesivo de comentarios?. Uso de nombres claros y descriptivos en variables y métodos. Crear archivos paralelos con explicaciones. Insertar diagramas de flujo. Eliminar toda documentación.

¿Qué ventaja tiene un buen nombrado frente a un comentario?. Hace que el código sea autoexplicativo. Aumenta el tamaño del archivo. Reduce la necesidad de tests. Mejora la velocidad de ejecución.

¿Qué tipo de nombres se recomiendan como alternativa a los comentarios?. Abreviados y técnicos. Claros y significativos. Numéricos y secuenciales. Compuestos por iniciales.

¿Qué es preferible a escribir muchos comentarios según el documento?. Escribir código expresivo y bien estructurado. Crear un manual anexo. Agregar iconos gráficos. Eliminar funciones complejas.

¿Qué debe documentarse en una clase?. Solo los constructores. Finalidad, atributos y métodos. Sólo los métodos privados. Sólo las excepciones.

¿Qué parte de un método debe ser documentada?. Parámetros, valor de retorno y descripción. Solo el nombre. Las variables internas. El tiempo de ejecución.

¿Qué etiquetas se usan comúnmente para documentar clases y métodos?. @run, @save, @end. @param, @return, @author. @data, @log, @loop. @code, @object, @main.

¿Qué lenguaje se menciona explícitamente en el documento como compatible con estas etiquetas?. Python. Java. HTML. JavaScript.

¿Qué herramienta permite generar documentación a partir del código fuente en Java?. Javadoc. Jupyter. Word. XMLParser.

¿Qué tipo de formato genera Javadoc como salida?. PDF. HTML. CSV. DOCX.

¿Qué contenido genera Javadoc automáticamente?. Descripción de clases, métodos y parámetros. Código ejecutable. Diagramas de casos de uso. Tablas de datos.

¿Qué herramienta, además de Javadoc, se menciona para generar documentación?. JavaFX. Doxygen. Eclipse Link. XAMPP.

¿Qué lenguajes admite Doxygen?. Solo Java. C, C++, Java y más. PHP y HTML exclusivamente. SQL y JSON.

¿Qué permite hacer Doxygen además de documentar?. Compilar código. Generar diagramas estructurales. Crear interfaces gráficas. Probar APIs REST.

¿Qué ventaja ofrece usar herramientas automáticas de documentación?. Eliminan la necesidad de comentarios. Ahorro de tiempo y consistencia en el estilo. Reemplazan al equipo técnico. Generan bases de datos.

¿Qué mejora aporta documentar correctamente una clase?. Facilita su comprensión y mantenimiento. Elimina errores. Reduce su tamaño. Aumenta el rendimiento.

¿Qué tipo de documentación incluye Javadoc si se usa correctamente?. Relación de clases y su uso. Registro de errores. Pruebas de seguridad. Estructura física del sistema.

¿Qué ventaja aporta usar etiquetas como @param en el código?. Evita compilar errores. Genera documentación clara sobre argumentos. Mejora el diseño gráfico. Optimiza el rendimiento.

¿Dónde se suele colocar la documentación generada con estas herramientas?. En la base de datos del proyecto. En archivos HTML accesibles por navegador. Dentro del IDE. En el servidor de correo.

¿Qué buena práctica se deduce del uso de herramientas como Javadoc y Doxygen?. Documentar de forma estructurada y automatizada. Sustituir el código fuente por documentación. Documentar solo al final del proyecto. Escribir comentarios visuales.