Principios de Reestructuraci贸n M.C. Juan Carlos Olivares Rojas Enero 2011
Contacto • Conceptos básicos • Pasos de la reestructuración • Problemas de la reestructuración • Herramientas para reestructuración
Criterios de Evaluación • 70% Examen escrito • 30% Desarrollo de portafolio evidencias (trabajos, tareas prácticas)
de y
Competencia Específica
• conoce los términos básicos de la reestructuración de código e identifica el problema de código mal desarrollado en el contexto de desarrollo de software.
Conceptos bรกsicos
Problemática
¿Si en lugar de programadores fuéramos constructores ¿cómo serían nuestros edificios, como el de la izquierda o como el de la derecha?
• “Código mutante” • “Diseño roto” • El código es antiguo y muy grande • Falta de planeación y documentación
Problemáticas
• ¿Qué malas prácticas de codificación tendría un edificio como el de la izquierda?
Problemática
• Debido a la complejidad del software y a la capacidad de las herramientas de software actuales se está generando muchas aplicaciones mal diseñadas que son ineficientes y difíciles de mantener.
Problemรกtica
โ ข El 80% del desarrollo de software es el mantenimiento (evoluciรณn) a sistemas existentes
Problemática
• En el pasado las prioridades eran tener un código rápido, pequeño (ocupa poca memoria), optimizado, utilizando los algoritmos mas eficaces etc…
• El software minimalista es todo un reto. El software debe de ser funcional.
Problemática
• Hoy en día el software debe de ser simple en su diseño y en su codificación.
• La reestructuración es parte de la reingeniería.
Problemática
• La reestructuración no sólo se da en código, sino en todo el proceso de desarrollo de software: datos, diseño externo, documentación.
Reingeniería • Es un proceso de mejora continua. En software se da al ir perfeccionando nuestro software iteración por iteración. • Las metodologías ágiles promueven las técnicas de reingeniería.
Definición
• Para Martin Fowler, es mejorar el diseño de código existente.
Definiciรณn
โ ข Para Roger Pressman es modificar el comportamiento interno (generalmente cรณdigo fuente) sin modificar su comportamiento externo (apariencia, funcionalidad).
Definición
• Si se llega a modificar su comportamiento externo formalmente no se le considera “refactorización” sino más bien una modificación.
Definición
• El término se creó como analogía con la factorización de números y polinomios. Por ejemplo, x² − 1 puede ser factorizado como (x + 1)(x − 1), revelando una estructura interna que no era visible previamente.
Definición
• La reestructuración de códigos no es una técnica para encontrar y/o corregir errores. • Para evitar cambiar el funcionamiento de un software se recomienda el uso de pruebas unitarias.
Historia • No es nada nuevo bajo el sol, se ha llevado a cabo de manera informal durante años • La tesis doctoral de William F. Opdyke (1993) es el primer trabajo conocido que examina específicamente esta técnica.
Historia
โ ข El libro de Martin Fowler Refactoring es la referencia clรกsica (1999) que trajo estรก constumbre al desarrollo de software actual.
โ ข XP popularizรณ el refactoring
Historia
• Para entender el concepto de reestructuración veremos un ejemplo práctico. • Generalmente se expresa la problemática (“bad smell”) para luego dar la solución.
Ejemplo
• Ejemplo 1: Getter/Setter • Problema: Hay un público en una clase
atributo
• Solución: hacer el atributo privado y proporcionar métodos de acceso público
Ejemplo 1
• En algunas ocasiones se muestra ejemplo en código: • public class Persona{ public int edad; ... }
Ejemplo 1
• La solución también se da a veces en código: public class Ejemplo1{ private int edad; public void setEdad(int val){ edad = val }
Ejemplo 1
public int getEdad(){ return edad; } } • ¿Por qué debemos hacer esto?
Ejemplo 1
Reestructuración • La reestructuración de códigos está basada en técnicas probadas por otras personas que en muchas ocasiones se dan como leyes pero que es necesario entender para mejorar nuestra práctica de programación.
Reestructuración • Por definición, los objetos tienen propiedades/carácterísticas/atributos (variables) que son propias y que no deben de ser modificables por otros, incluso objetos del mismo tipo.
Reestructuración • Si una persona tiene un atributo peso este no puede ser modificado al azar (una persona tiene 60 kilos y de repente ya 65) sólo a través de un comportamiento/hablidad (método) como hacerEjercicio() o comerGolosinas().
Reestructuración • ¿Esto implica que cada atributo de la clase debe tener métodos get/set? • No, sólo aquellos elementos que deban sr modificados en el exterior. Es como el caso de los métodos privados.
Reestructuración • ¿En que ocasiones se recomienda que los atributos de una clase sean públicos? • Cuando son constantes numéricas. • ¿Que propiedad de POO se utilizó en este refactoring?
Encapsulamiento
• Un refactoring no siempre aplica en todos los contextos.
Encapsulamiento
• Los refactorings están basados en premisas cuyo objetivo en la mayoría de los casos es que el código sea más legible.
Tarea
• Traer instalada una herramienta de modelado en UML. Recomendación StarUML. • Darle un repaso a la propiedad de encapsulamiento de POO
Motivos para Refactorizar • Calidad • Eficiencia • Diseño evolutivo en lugar de un gran diseño industrial • Evitar la reescritura de código.
¿cuándo refactorizar? • La refactorización no es la cura para todos los males pero ayuda a ser más extensible el software: • Cuando el software no es claro • Ayuda a evitar redundancia de código originando en muchos casos menor tamaño.
¿cuándo se debe refactorizar? • Aplicar la “Regla de Tres”: 1. Para añadir funcionalidad
una
nueva
2.Cuando se necesita localizar un error 3.Como revisión de código
Algunas consideraciones • Refactoring va más allá de limpiar código. • La refactorización es el arte de mejorar de manera segura, el diseño de código existente. • Refactorización no es reescribir todo desde cero.
Algunas consideraciones โ ข La refactorizaciรณn no se calendariza
• Funciona bien • Comunica lo que esta haciendo • No tiene duplicación
Código Simple
• El refactoring ayuda a la simplificación de código, alguna de sus ventajas son:
• Es más seguro
• Es más legible • Es más sencillo ser iterativo en el desarrollo de software •
Código Simple
• Es menos propenso a errores
• ¿Cuál de los dos códigos siguientes es lo más correcto?
Ejemplo 2
• Caso1: double calcRngMaxPer() {.... } ¿Qué hace el método?
Ejemplo 2
• Caso 2: double calcularRangoMaximoPermiti do() {.... } • Se recomienda este segundo caso por ser más legible • ¿cómo se llamo el refactoring?
• El refactoring anterior “renombrar método”
fue
• Solucion: cambiar el número mágico por una constante
Ejemplo 3
• Problema: El cambio de valor de un número mágico implica un cambio en todo el código con su pérdida de tiempo.
• Considérese el siguiente código:
Ejemplo 3
class CalculoSimple { public static double CalcularCincunferencia (double diametro) { return 3.14 * diametro; } }
• La solución queda así:
Ejemplo 3
class CalculoSimple { public final double PI = 3.14; public static double CalcularCincunferencia (double diametro) { return PI * diametro; } }
• En algunas ocasiones los refactorings se dan en diagramas arquitectónicos:
¿Es correcto este modelo? ¿Cómo se puede mejorar?
Ejemplo 4
• Si. Subiendo el mÊtodo a su clase padre.
Ejemplo 4
• ¿En qué casos no sería conveniente esta refactorización? • Cuando los métodos difieren en su implementación. ¿Pero aun así es mala?
Ejemplo 4
• Aun se puede optimizar subiendo el método pero sin implementarlo en la clase padre y sobreescribiéndolo en las clases hijas.
Ejemplo 4
Actividad
• Se necesita implementar una clase rectángulo para un programa tipo “Paint”. Trate de utilizar encapsulamiento para modelar la clase si se considera que tiene los métodos área(), dibujar(). Complete los atributos faltantes. • Escriba su solución en una herramienta de modelado o bien en un pedazo de hoja de papel con su nombre, en caso de no tener equipo de cómputo.
Solución • Pueden existir diversos modelados, lo importante es diseñar nuestro código para ser extensible. Por este motivo, es importante manejar encapsulamiento, polimorfismo y herencia. • El modelado puede ser textual o gráfico.
Solución
• General: • Atributos: x1,y1, x2, y2: int • Óptimas: • Atributos: ancho, alto: int • Origen: punto
• Atributos: esqSupIzq, esqInfDer: punto
Solución
• Clase: Punto • Atributos: X, Y: int • Métodos: getX(), setX(), getY(), setY(): int • Debemos de quitarnos la idea de que si compila y el programa hace lo que debe de hacer no implica que el software esté realmente correcto.
Soluci贸n
Soluciรณn โ ข Se recomienda utilicen el estรกndar XMI para hacer portable sus diagramas
Práctica de Refactoring
• Las metodologías ágiles y esbeltas proponen realizar modelado sobre lápiz y papel o sobre pizarrones para evitar pérdida de tiempo. • A continuación se muestra un ejemplo de ello.
Prรกctica de Refactoring
โ ข Tomado http://www.agilemodeling.com
Codificar este modelo
Práctica
• Una vez desarrollado el modelo, probar con los siguientes valores e indicar su resultado: • • • • •
6 19 28 43 118
• Los resultados obtenidos deben de ser:
Práctica
• • • • •
6 es perfecto 19 no es perfecto 28 es perfecto 43 no es perfecto 118 no es perfecto
Práctica
• Una vez desarrollado el modelo, ¿Detectas alguna mala práctica de programación? • Al parecer en algo tan pequeño podría ser que no existieran malos diseños o prácticas de programación…
Prรกctica
import javax.swing.*; public class programa1 { public static void main (String[] args){ int Num=Integer.parseInt(JOption Pane.showInputDialog("Introd uce numero")); int i=1; int suma=0;
Práctica
while(i<=(Num/2)){ if(Num%i==0){ suma+=i; i+=1;} else{ i+=1;} } if(Num==suma) JOptionPane.showMessageDialo g(null,"El numero "+Num+" es un número perfecto");
Práctica
else JOptionPane.showMessageDialog( null,"El numero "+Num+" no es un número perfecto"); }} • No tomar en cuenta el mal sangrado
• En realidad hay algunas.
Práctica
• La primera de ellas es la conjunción o mezcla de la lógica de la aplicación con la presentación. • Un objeto debe de realizar solo las cosas pertinentes al objeto.
Práctica Refactoring
• Para solucionar esta problemática podemos aplicar el “”principio de separación de interfaces”; para ello, realizar lo siguiente: • Reestructurar para tener la siguiente firma de método: public boolean esPrimo(int n){
Práctica de Refactoring
… return true/false } • En el método main(){} hacer las adecuaciones necesarias para la lectura de datos, la invocación de la funcionalidad y la impresión de resultados
Práctica de Refactoring
• ¿Cómo visualizas la aplicación?¿Crees que aun se pueda mejorar? • En general tenemos una pequeña clase que implementa la lógica y la presentación. Si bien es cierto que ya está separada aun está en la misma clase
Práctica de Refactoring
• Para ello, refactorizaremos a la siguiete arquitectura: • App • +main(String args…):void • Numero • +esPerfecto(int):boolean
Práctica de Refactoring
• ¿Aún hay más problemas? • Bueno en realidad este pequeño programa puede ser mejorado con la colocación de comentarios en el código. • La mejor forma es a través de la autodocumentación del código.
Práctica de Refactoring
• La autodocumentación del código se puede hacer con compiladores de documentación como JavaDoc • Javadoc es una herramienta de autodocumentación de código que genera dicha documentación en formato HTML.
Práctica de Refactoring
• Se deben utilizar los comentarios especiales /** …..*/ con algunas palabras clave para determinar la documentación. • Las palabras clave inician con una arroba. • Se puede incrustar cualquier etiqueta de HTML.
Práctica de Refactoring
• @author nombre_desarrollador • @deprecated descripción //indica un método que no se recomienda su uso • @param nombre descripción
Práctica de Refactoring
• @return descripción • @see referencia //asocia con otro elemento el cual puede ser: #método(); clase#método(); paquete#método(); paquete.clase#método(). • @throws clase descripcion • @version versión
Práctica de Refactoring
• La documentación se crea de la siguiente forma: javadoc archivo.java • En NetBeans se puede encontrar la opción en el menú Build en la opción Generate JavaDoc for …
Ejemplo Javadoc
/** * Thrown to indicate that the application has attempted to convert * a string to one of the numeric types, but that the string does not * have the appropriate format. * * @author unascribed * @version 1.16, 02/02/00 * @see java.lang.Integer#toString()
Javadoc
* @since JDK1.0 */ public class NumberFormatException extends IllegalArgumentException { /** * Constructs a <code> NumberFormatException </code> with no detail message. */ public NumberFormatException () { super(); }
Javadoc
/** * Constructs a <code> NumberFormatException </code> with the * specified detail message. * @param s the detail message. */ public NumberFormatException (String s) { super (s); } }
Laboratorio 1
• Utilizar la herramienta Analyze Javadoc de Netbeans para determinar la documentación faltante. • Agregar una nueva funcionalidad esPrimo() • Reestructura los códigos anteriores para que ahora estén en inglés.
Practica de Refactoring • ¿Sigue habiendo problemas? • En realidad no, lo que se acostumbra a realizar no es crear pequeños programitas para probar objetos sino más bien utilizar herramientas automatizadas de pruebas unitarias como JUnit
Pruebas Unitarias
• Las pruebas unitarias se realizan sobre los bloques principales de construcción de códificacion. En nuestro caso de las clases. • La idea es tener pruebas automatizadas que desarrollar nuestras propias pruebas para revisar el código.
JUnit
• Es el framework de pruebas unitarias para Java más utilizado en el mundo. • En IDEs como Netbeans y Eclipse viene de manera predeterminada. • Para crearlo en Netbeans es muy fácil sólo se escoge la opción de crear una prueba unitaria de una clase existente y crea un bosquejo de prueba con cada método impelementado.
JUnit
• Existen dos versiones populares a manejar la 3.x (anticuada pero ampliamente utilizada) y la 4.x (que maneja anotaciones pero no es compatible con versiones viejas). • La ventaja de utilizar pruebas unitarias es que nos permite corroborar nuestro código sin necesidad de crear una aplicación.
JUnit
• En la versión 3.x las pruebas unitarias tienen la siguiente forma: • Se importa junit.framework.TestCase;
la
clase
• La clase de prueba hereda de TestCase • Se puede utilizar utilizar un constructor para inicializar datos.
JUnit
• Se utiliza el método setUp() para realizar un conjunto de acciones antes de evaluar un caso de prueba. • Se utiliza el método tearDown() para realizar acciones una vez finalizado el caso de prueba • Se utiliza el método fail() que recibe una cadena de mensaje de error para forzar a una falla.
JUnit
• Se utiliza el método assertEquals(valoresperado, valorresultante) para saber si el método se ejecutó de manera exitosa. • Se puede utilizar el método assertNotNull(objeto) para saber si un objeto no es nullo. • Para tipos de datos flotantes el método assertEquals utiliza un parámetro adicional
JUnit
• La diferencia con la versión 4.x de Junit radica en lo siguiente: • Se importan las siguientes clases: org.junit.After, org.junit.AfterClass, org.junit.Before, org.junit.BeforeClass, org.junit.Test, org.junit.Assert.*; • Se utilizan las anotaciones @BeforeClass, @AfterClass, @Before, @After para indicar cuando se utilizan los métodos auxiliares
JUnit
â&#x20AC;˘ La clase de prueba no extiende de ninguna otra pero cada caso de prueba debe utilizar la anotaciĂłn @Test â&#x20AC;˘ Se recomienda realizar los casos de prueba de manera separada uno por uno y dejarlos siempre presente.
Práctica • Crea pruebas unitarias “testear” el código anterior.
para
• ¿cuántas pruebas se necesitan para corroborrar nuestro código? • Documenta las pruebas que se hicieron al inicio de toda la dinámica.
Práctica • Se tienen dos métodos diferentes, por lo cual se requiere al menos dos pruebas unitarias. • No puede haber pruebas exhaustivas sobre el código. • Se deben considerar casos válidos e inválidos
Pasos en la reestructuraci贸n
• Un paso a la vez
• Mejorar el diseño una vez que se ha escrito el código
Pasos
• De pasos sencillos (refactorings) se logra mejorar sustancialmente el código fuente.
Metodología
• Escribir pruebas unitarias y funcionales. (Se es muy riesgoso si no se tienen) • Refactorizar los fallos de diseño.
principales
• Refactorizar un malor olor aunque sea sencillo y probar.
Metodología
• Cuando se desarrollo software utilizando métodos ágiles, el tiempo de desarrollo se divide en dos: 1. Agregar funcionalidades 2.Refactorizar
nuevas
Metodología
• Cuando se agrega nueva funcionalidad no se modifica código existente, la única forma de medir el avance es a través de pruebas unitarias. • Cuando se refactoriza, no se agregas pruebas unitarias
Metodología
• Al realizar cambios en el código, la estructura de software es modificada y por lo tanto es necesario refactorizar. • A continuación se detalla un pequeño ejercicio aplicando el refactoring de Encapsulated Field
• Formar equipos de dos personas
• Escribir lo que consideran relevante (10 mint)
Investigación
• Leer la hoja que les corresponda del artículo Refactoring – Does it improve software quality? (15 min)
• Conclusiones (10 minutos)
Investigación
• Socializar al resto del grupo sus ideas. (10 minutos)
• Los pasos a seguir son: • Crear los méodos get y set para cada atributo que se desea acceder.
Ejercicio
• Localizar todas las referencias y reemplazar todos los accesos a los campos con los métodos get y todas las asignaciones con set. • Compilar y cambiar después de cada referencia.
Ejercicio
• Declarar el campo como privado. • Compilar y probar. • Inicialmente se tiene el siguiente código:
Ejercicio
public class Persona { public String name } Se tiene la unitaria
siguiente
@Test public void prueba(){
Ejercicio
prueba
Person person; person.name = “Juan Pérez”; assertEquals(“Juan Pérez”, person.name); } • Después se aplica el paso 1 (crear métodos get y set):
Ejercicio
public class Person { public String name; public String getName() {return name;} public String setName(String NewName){ name=NewName; }
Ejercicio
• Ahora se aplica el paso 2: Encontrar todos los clientes; reemplazar referencias con llamadas. Se modifica la primera referencia. • Antes: person.name = “Juan Pérez”; • Después: person.setName(“Juan Pérez”);
Ejercicio
• Se compila y prueba. Ahora se sigue con la reestructuración de la siguiente referencia: • Antes: assertEquals( “Juan Pérez”, person.name); • Después: assertEquals( “Juan Pérez”, person.getName());
Ejercicio
• Se compila y vuelve a probar. Una vez que se ha probado que funciona se sigue el paso 4 de hacer privado el campo: public class Person{ private String name; ……}
Ejercicio
Problemaas de la reestructuraci贸n
Problemas • Reestructurar es riesgoso. • ¿entonces cómo debe hacerse? • De manera metículosa y paso a paso
¿por qué no refactorizamos? • Generalmente se pide una extensión a un sistema, y ni siquiera se comprende completamente lo que se va a hacer, cuando ya hay que hacerlo. • ¿Porqué voy yo a corregir lo que otros hicieron mal?
¿por qué no refactorizamos? • ¿Qué me garantiza que al “corregir” el código, el programa siga funcionando tal como al principio? • Hay que cumplir con la fecha de entrega comprometida, es LA PRIORIDAD NUMERO UNO!
¿Qué pasa si no se refactoriza? • Con el tiempo, los errores se propagan a sí mismos. • El diseño del programa se corrompe. • El costo incremental de cambios se escala
Otros Problemas • Los desarrolladores de software no entienden bien el concepto y creen que es solo copy-paste profesional. • ¿para que lo hago si yo no disfrutaré esos beneficios?
Otros Problemas • Pondré al descubierto mi forma de codificar (buena o mala) al dejar componentes reusables. • El principal problema al refactorizar es el problema humano, sobre todo si se trabaja en equipo.
Otros Problemas â&#x20AC;˘ Muchas aplicaciones son totalmente dependientes de cierta estructura como las bases de datos, por lo que al hacer refactoring implica en muchos casos parar procesos.
• Como pudo observar en el artículo previo. • No necesariamente el refactoring mejora la calidad de un sw. De hecho al hacer el código más claro, puede hacer más lento el código.
Refactoring y desempeño del sw
Herramientas para Reestructuraci贸n
• Actualmente existen muchas herramientas que permiten el manejo de refactorings aunque sea simples.
Herramientas
• En un principio el refactoring se hacia de forma manual siendo en la mayoría de los casos todo un arte.
• Generalmente no se utilizan en mucha frecuencia por que en ocasiones es más fácil desarrollarlas a mano.
Herramientas
• Estas herramientas de refactoring se encuentran incluidas dentro de los principales IDEs
• Toda herramienta de refactoring debe de ser capaz de seguir funcionando aun después de haber hecho la reestructuración
Herramientas
• Los factores a considerar en la elección de una herramienta son variables.
• Existen varias herramientas pero destacan principalmente xRefactory y RefactoryIT
Herramientas
• Se debe tomar en cuenta el catalogo y complejidad de los refactorings, así como la velocidad de ejecución y que se cuente con la opción de deshacer.
Actividad
• En equipos de dos personas seleccionadas por el profesor, determinar un ejemplo del catálogo de refactorizaciones de NetBeans. • Para ello se deberá investigar en que consiste el refactoring asignado, y dar un ejemplo de cómo utilizarlo. • Revisar cuales de ellas están en el libro de Fowler.
Actividad • Entregar un breve reporte en digital que se discutirá en clase. • Algunas refactorizaciones son muy simples y su nombre prácticamente las describe, otras tendrán que investigarse.
Catálogo de Ref. de NetBeans
• Asignación 1:
– Renombrar (Rename) – Mover (move) – Copiar (copy) – Eliminar de forma segura (Safely Delete)
• Asignación 2:
– Cambiar los parámetros del método (Change Method Parameters)
Catálogo de Ref. de NetBeans
• Asignación 3:
– Ascender (Pull Up) – Descender (Pull Down)
• Asignación 4:
– Mover de nivel interior a exterior(move inner to outer level)
• Asignación 5:
– Convertir anónimo annonymus to inner)
en
miembro
(convert
Catálogo de Ref. de NetBeans
• Asignación 6:
– Introducir variable (introduce variable) – Introducir constante (introduce constant) – Introducir campo (introduce field)
• Asignación 7:
– Introducir método (replace block code with a field) – Encapsular campos (encapsulate fields)
Catálogo de Ref. de NetBeans
• Asignación 8:
– Pull Up & Push Down (Ascender y Descender)
• Asignación 9:
– Extract Interface (Extraer Interface)
• Asignación 10:
– Extract Superclass (Extraer superclase) – Use Supertype Where Possible (usar supertipo cuando sea psible)
Prรกctica 2
• Hacer revisión formal del código proporcionado. Se utilizará el método de Fanagan: • Especificación de Requerimientos • Arquitectura del Sistema (hasta aquí)
Laboratorio 2
• Técnica de Programación (estilo de codificación que se verá en las siguientes diapositivas) • Pruebas unitarias • Las revisiones de código se planifican y se reúnen generalmente en equipos de trabajo.
Laboratorio 2
â&#x20AC;˘ Generalmente los roles son: autor, lector, probador y moderador. â&#x20AC;˘ Para el caso de comparativa se manejan estĂĄndares de referencia como los anteriormente vistos (javadoc)
Laboratorio 2
• Una de las notaciones de estilo de codificación más utilizadas es la “notación camello-húngaro” • Esta notación está basada en dos estándares: camello (Java) y Húngara (Microsoft)
Laboratorio 2
• La notación húngara fue creada por Charles Simonyi de Microsoft, el cual es húngaro y por eso recibió ese nombre. • Consiste en tener variables autodocumentadas agregando un prefijo de tres caracteres o menos para indicar su tipo.
Laboratorio 2
Descripción
Abr
Objeto (parecido a las estructuras)
o*
Manejador (handler)
h p
Descripción
Abr
Carácter con signo
c
Carácter sin signo
b
Entero
n
Palabra (entero sin signo)
w
Puntero a entero de 16 bits
lp
Doble palabra (entero 32 bits)
dw
Puntero largo (32 bits) Enumeraciones
Largo
l
Flotante
f
Doble
d
Cadena terminada en /0
sz
Estructura Abc
sA
Descripción
Abr
Formulario
frm
CheckBox
chk
Botón
cmd
Imagen
img
e
Etiqueta
lbl
Puntero largo a una cadena terminado en nulo
lpsz
Menú
mnu
PictureBox
pic
Puntero largo a una función que devuelve un entero
lpfn
TextBox
txt
ComboBox
cbo
Línea
lin
Laboratorio 2
• Ejemplos: • int nTest; • long lTemp; • char *szString = "Prueba";
Laboratorio 2
• La principal característica de la notación húngara consiste en que no separa nombres de identificadores (variables, métodos, objetos) con “_” para palabras compuestas.
Laboratorio 2
• Los identificadores tienen la forma de la joroba de un camello. Sigue respetando mucho de la Notación C. • Los métodos inician en minúsculas y si hay una palabra compuesta esta inicia con mayúscula dando la apariencia de una joroba.
Laboratorio 2
• Las clases inician con mayúscula siguiendo el mismo método. • Los métodos para acceder a atributos de las clases no públicos deben llamarse por convención set y get.
Laboratorio 2
Convenciones de Desarrollo
• Algunas compañías como Google proponen sus propios estándares de codificación: http://code.google.com/p/google-styleguide/ • Los lenguajes que maneja son C/C++, Python, Perl, Objective-C, XML, entre otros. • Estos estándares son manejados en forma obligatoria para el desarrollo de sus proyectos.
• Reestructurar programa para que este en notación “camello húngaro”.
Laboratorio 2
Dudas