tema 4-6 (Comentarios, Formato, Objetos y Estructuras de Datos) Codigo Limpio(R.
![]() |
![]() |
![]() |
Título del Test:![]() tema 4-6 (Comentarios, Formato, Objetos y Estructuras de Datos) Codigo Limpio(R. Descripción: codigo limpio |




Comentarios |
---|
NO HAY REGISTROS |
La abstracción efectiva de datos, en el diseño de software, busca principalmente: Exponer los detalles de implementación mediante variables públicas o getters y setters directos. Mostrar interfaces abstractas que permitan la manipulación de la esencia de los datos, sin revelar su representación interna. Limitar la visibilidad de las variables a privado, sin considerar la forma en que se interactúa con ellas. Facilitar el acceso a cada componente de los datos de forma individual. En el ámbito del diseño de software, las estructuras híbridas son consideradas problemáticas porque: Son una solución óptima que combina las fortalezas de los objetos y las estructuras de datos. Ofrecen una encapsulación robusta al tener métodos y datos privados. Presentan características de objetos (funciones significativas) y de estructuras de datos (variables públicas o expuestas), lo que dificulta tanto la adición de nuevas funciones como de nuevos tipos de datos. Son simplemente una variante de los Objetos de Transferencia de Datos (OTD) con métodos adicionales. Un Objeto de Transferencia de Datos (OTD) representa la esencia de una estructura de datos porque su propósito fundamental es: Encapsular la lógica de negocio compleja y realizar operaciones significativas. Integrar métodos de navegación y reglas de negocio para una gestión integral. Servir como un contenedor simple de datos, generalmente con variables públicas (o getters y setters sin lógica), utilizado para la comunicación entre componentes. ¿Qué prefiere el autor ante código confuso?. Escribir comentarios detallados. Eliminar el código. Refactorizar para que el código exprese la intención. Ignorar la confusión y avanzar. ¿Qué significa “balbucear” en comentarios?. Escribir comentarios ilegibles por mala ortografía. Es añadir un comentario sin razón o solo por cumplir, que no comunica nada. Usar demasiados comentarios en inglés. Hacer comentarios largos en lugar de cortos. ¿Cuándo sí son válidos o útiles los comentarios, según el texto?. Cuando ayudan a decorar el código. Comentarios legales (licencias/derechos de autor) y Javadoc en API públicas. Cuando explican cada línea del código. Cuando reemplazan a los nombres de variables. Cuál es el tamaño recomendado para un archivo fuente?. Entre 50 y 100 líneas. Máximo 200 líneas. Alrededor de 200 líneas, con un límite de 500. No hay límite, depende del programador. ¿Cuáles son reglas sobre la declaración de variables?. Las variables locales deben aparecer en la parte superior de la función. Las variables de control de bucle deben declararse dentro del bucle. Todas las variables deben declararse al inicio del archivo. Las variables de instancia deben declararse al inicio de la clase. ¿Qué principios rigen el “formato horizontal” del código?. No usar espacios en blanco alrededor de operadores. Separar con espacios los operadores de asignación para distinguir lado izquierdo y derecho. No dejar espacio entre nombre de la función y el paréntesis de apertura. Alinear todas las declaraciones con tabulaciones para que se vean iguales. ¿Qué reglas de equipo propone respecto al formato?. Cada programador debe aplicar el estilo que más le guste. Todos los integrantes deben acordar un único estilo y aplicarlo en conjunto. El objetivo es lograr coherencia en el software. No es necesario configurar el IDE, basta con disciplina individual. |