Transcript Reestructuración de Códigos

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.
• La reestructuración de códigos
no es una técnica para encontrar
y/o corregir errores.
Definición
• 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 atributo público
en una clase
• 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.
• Traer instalada una herramienta
de
modelado
en
UML.
Recomendación StarUML.
Tarea
• 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 una nueva funcionalidad
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
• Es más fácil de mntener
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
calcularRangoMaximoPermitido(
) {.... }
• 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
• Una vez desarrollado el modelo,
probar con los siguientes valores
e indicar su resultado:
Práctica
•
•
•
•
•
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
• Una vez desarrollado el modelo,
¿Detectas alguna mala práctica
de programación?
Práctica
• 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(JOptionP
ane.showInputDialog("Introduce
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.showMessageDial
og(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
siguiente firma de método:
public boolean esPrimo(int n){
la
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 la clase junit.framework.TestCase;
• 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
• La clase de prueba no extiende de ninguna otra
pero cada caso de prueba debe utilizar la
anotación @Test
• Se recomienda realizar los casos de prueba de
manera separada uno por uno y dejarlos
siempre presente.
Práctica
• Crea pruebas unitarias para “testear”
el código anterior.
• ¿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 principales fallos
de diseño.
• 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 nuevas funcionalidades
2.Refactorizar
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
personas
de
dos
• Escribir lo que
relevante (10 mint)
consideran
Investigación
• Leer la hoja que les corresponda
del artículo Refactoring – Does it
improve software quality? (15
min)
• Socializar al resto del grupo sus
ideas. (10 minutos)
Investigación
• Conclusiones (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 siguiente prueba unitaria
@Test
public void prueba(){
Ejercicio
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
• 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
• Generalmente los roles son: autor,
lector, probador y moderador.
• 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