Carlos Fontela

cfontela@fi.uba.ar

Buenas prcticas de programacin

A.

B.

C.

D.

E.

Siempre conviene que los programas se

ejecuten lo ms rpido posible
La razn principal para no repetir cdigo es
evitar escribir lo mismo dos veces
El cdigo se lee muchas ms veces que las
que se escribe
Antes de agregar un comentario para
aclarar, debera tratar de aclarar el cdigo
Al programar una clase, conviene prever
todo lo que se vaya a necesitar, para
incluirlo desde el principio

Los necios obedecen las reglas; los sensatos,

las usan como gua (Douglas Bader)
El cdigo es el nico artefacto del desarrollo
de software que siempre se va a construir
(Carlos Fontela)
Im not a great programmer; Im just a good
programmer with great habits (Kent Beck)

2c2014

Qu importa ms?
Cdigo claro y mantenible
Desempeo (performance) de la aplicacin
Performance del usuario
Portabilidad a distintos ambientes

Depende del cliente y de la aplicacin (criticidad,

longevidad)
5

2c2014

Legibilidad
Guas para mejora de desempeo
Buenas prcticas de XP

2c2014

2c2014

El cdigo se escribe una vez y se lee muchas

Escribir cdigo para humanos

En un texto usamos:
Ttulos de distinto nivel
Sangras
Signos de puntuacin
Tipografas especiales

Por qu no hacer el cdigo legible?

2c2014

Now listen. We are paying $600 an hour for this

computer and $2 an hour for you, and I want you
to act accordingly.
Segn Barry Boehm, lo que su jefe le dijo en su primer
trabajo (1950s)

2c2014

Se entiende por qu?

Extraer mtodos
Extraer clases, por delegacin o
por generalizacin

10

2c2014

Nombres
Formatos: lneas en blanco, sangras, etc.
Comentarios
=> Cdigo autodocumentado

11

2c2014

Suponer igual nivel del desarrollador que va a

necesitar mi cdigo
Evitar lucirse
No explicar lo obvio

12

2c2014

Descriptivos
lineasPorPagina es mejor que lpp
distanciaEnMetros es mejor que distancia
Poner antnimos en forma consistente: mayor, menor / min, max
No usar nmeros: total1, total2

Trminos del problema, no de la solucin

empleados en vez de arregloEmpleados

Casos especiales (?)

Salvo en nombres muy largos: num, cant, long, max, min
i, i, k, para ndices
tmp, temp, para temporales y auxiliares

13

2c2014

Evitar significados ocultos

long es la longitud del documento, o -1 si no se encontr

Legibles en algn idioma

Variables booleanas
encontrado, terminado, error
No expresarlas en forma negativa
Que se lean como verdadera o falsa:
sexo no es buen nombre

14

2c2014

Que describa todo lo que hace el mtodo

Que describa la intencin (el qu) y no detalles de
implementacin (el cmo)
borrar: nombre
Malos sucedneos: procesarElemento,
buscarElementoBorrar, buscElBor, beb, buscarBorrar,
findElementoDelete

15

2c2014

Tratar de que no dependan de un orden de

ejecucin
Si no, documentarlo adecuadamente

Recursividad slo cuando ayuda a la legibilidad

Y slo al nivel de un mtodo
No: A -> B -> A

Que afecte a la clase en la que est declarado

Si es as, suele tener el nombre de otra clase en su
nombre
Si no, moverlo de clase

16

2c2014

Que no sean muchos

Ninguno es lo mejor

Que estn ordenados con algn criterio

Mantener el criterio en diferentes mtodos

Chequear valores vlidos a la entrada

En las referencias, ver que no estn en nil

Los valores de entrada no deben cambiarse

17

2c2014

Inicializacin: siempre explcita

Un uso para cada variable
Vida de la variable lo ms corta posible
Usar mtodos booleanos para guardar partes
de tests complicados
if ( (anio % 400 == 0) ||
((anio % 4 == 0) && (anio % 100 != 0) )

18

2c2014

( 1 to: 14) do: 14 clientes

(usuario id = 1234) ifTrue: []

Evitar todo hardcodeo o nmeros

mgicos
Por qu?
Salvo algunos 0, 1, , nil, y cosas que no cambian

19

2c2014

No tener miedo de usar espacios

(a=b)ifTrue:[Transcript show:OK]
(a = b) ifTrue: [ Transcript show: OK ]
Usar lneas en blanco
Usar parntesis sobreabundantes para aclarar
Usar layouts del lenguaje

20

2c2014

Son buenos para aclarar cdigo

Aunque deberamos tratar de aclarar el cdigo antes

O como resumen de una secuencia de acciones

Aunque deberamos tratar de separar en un mtodo

No repetir en los comentarios lo que dice el cdigo

asigno 1 a x:
x := 1.

Corolario: no deberan abundar

21

2c2014

Que los comentarios sean fciles de mantener

El comentario debe ir antes del cdigo al que se
refieren
Preparan mejor al lector
A veces conviene ponerlos al final de la lnea

Casos especiales a documentar con comentarios

Efectos laterales
Restricciones de un mtodo o clase
Nombres de algoritmos, fuentes (de dnde lo saqu)

22

2c2014

Cuidar los >=, <=, >, <

Ojo con anidaciones profundas
No ms de 3 niveles

Ordenar los case de los switch

Orden lgico: alfabtico, numrico

Hacer obvio al lector la manera de salir del

ciclo
Usar salidas explcitas de ciclos cuando se
pueda
O incluso retornos de mtodos
23

2c2014

Das de un mes
diasMes := #(31 28 31 30 31 30 31 31 30 31 30 31 ).
( (mes > 0) & (mes <= 12) )
ifTrue: [resultado := diasMes at: mes]
ifFalse: [Error signal new].
( (mes = 2) & (anio bisiesto) )
ifTrue: [resultado := 29]

Es mejor que un switch?

Depende de cada uno
24

2c2014

Por qu no conviene ser ingenioso al

escribir cdigo?
A qu llamamos nmeros mgicos?
Cules son las dos teclas que ms debemos
usar del teclado?
Cul es el nmero ideal de parmetros de un
mtodo?

27

2c2014

Resistir la tentacin
No siempre el usuario percibe las mejoras en el
cdigo, sino que privilegia su propia experiencia
Mejorar el hardware?

Cuando todo falle

Mejoramos el cdigo
Pero slo en las partes crticas
(recordar a Paretto: 80-20)
Usar profilers si los tenemos

28

2c2014

Evitar el uso de memoria externa cuando se puede

usar memoria interna
Accesos innecesarios a disco

En las evaluaciones lgicas, utilizar la opcin de

cortocircuito
En un (a & b) ifTrue: no necesitamos evaluar b si a
es falso
En un (a | b) ifTrue: no necesitamos evaluar b si a
es verdadero
Verificar si el entorno no lo hace solo

29

2c2014

Ordenar las preguntas en acciones if

compuestas y switch
Conviene evaluar primero las ms frecuentes y
menos costosas de evaluar
switch (mes) {
case 1, 3, 5, 7, 8, 10, 12 : dias = 31; break;
case 4, 6, 9, 11 : dias = 30; break;
case 2
if (anio.bisiesto())
dias = 29;
else dias = 28;
break;
default: throw new MesInvalidoException();
}
30

2c2014

Calcular todo lo que se pueda antes de entrar a un

ciclo
// mal ejemplo:
f1 leerFecha.
f2 leerFecha.
100 timesRepeat: [
periodo f1 diasHasta: f2.
periodoDoble := periodo * 2.
f3 := Fecha hoy.
i := i+1;
Transcript show: i * periodo + periodoDoble ]

Usar tipos por valor siempre que se pueda

31

2c2014

Usar tipos enteros en vez de punto flotante

int mejor que double

Tabular datos en vez de usar funciones

trascendentes
Salvo que se requiera mucha precisin
En algunos casos es sencillo

Liberar memoria que ya no se necesita, si el entorno

no lo hace solo
Usar lenguajes compilados o de menor nivel
Assembler >> C++ >> Java / C# / Smalltalk >> PHP /
Python
Si la modularizacin es buena, podemos acotarlo

32

2c2014

Probar su efectividad
Muchas presuntas mejoras no resultan, porque
los compiladores, entornos de ejecucin y
otros, las introducen en forma automtica
No hay expertos generalistas
Hay cosas que han cambiado con el tiempo
P. ej., llamadas a funciones, arreglos
multidimensionales

33

2c2014

Premature optimization is the root of all evil

(Donald Knuth)

1. Make it work.
2. Make it right.
3. Make it fast.
(Kent Beck)

Por qu no conviene optimizar todo desde el

comienzo?
Cmo sabemos que una optimizacin dio sus
frutos?

37

2c2014

Extreme Programming o Programacin Extrema

Conjunto de prcticas de desarrollo centradas en la
programacin
Uno de los mtodos giles
Ms adelante volvemos

Lleva al extremo las buenas prcticas de programacin

y cuestiones de sentido comn

Veremos slo un poco

Y leern tambin

38

2c2014

Probar programas es bueno?

Hacer pruebas unitarias y funcionales todo el tiempo
El desarrollo es dirigido por las pruebas: Test-Driven
Development (TDD)
Se disean antes de codificar
Ojo: mucha disciplina

Los diseos de software son cambiantes?

El diseo evoluciona junto con la programacin
Lo hacen los propios programadores
Minimizar documentacin que se guarda, si no se la va a
mantener actualizada
39

2c2014

Hacer pruebas de integracin es importante?

Integracin sigue inmediatamente a las pruebas
unitarias
Evita que sea cada vez ms complicado integrar cdigo
de varias fuentes

Revisar la calidad del cdigo es recomendable?

Revisar cdigo todo el tiempo
Pair-programming
Se mantiene ms el foco

Refactorizaciones

40

2c2014

Estndares de codificacin permiten una mejor

comunicacin y reducen errores?
Fijar estndares precisos y estrictos

El desarrollo incremental es positivo?

Hacer iteraciones muy cortas
Disear una pequea porcin, codificarla y probarla
Preocuparse slo por lo que se est haciendo
Nada por adelantado
Recordar: el cliente pide (requerimientos), no
necesariamente lo que quiere (expectativas), ni mucho
menos lo que necesita (necesidad)

41

2c2014

Simplicidad
The simplest thing that could possibly work
Complejidad dificulta refactorizaciones,
comunicacin y depuraciones
No implementar lo que no se sabe si servir,
y en el 80% de los casos no sirve

Se mantiene baja la inversin inicial en el proyecto

El cdigo ejecutable permanece ms chico
YAGNI

La simplicidad cuesta trabajo y es fruto de un

buen diseo
42

2c2014

Prioridades
1.
2.
3.
4.

Cdigo autodocumentado
Embebida en el cdigo (comentarios)
Pruebas unitarias
Otras pruebas automatizadas

Menor valoracin a
UML
Documentos externos

aunque no se descartan

No repetirs cdigo
No dejars a tu prjimo lo que no quieres que
te dejen a ti
Escribirs cdigo legible
Usars la barra espaciadora y el salto de lnea
de tu teclado
La optimizacin prematura es la raz de todos
los males (Donald Knuth)

45

2c2014

Continuous Integration, de Martin Fowler

Lo tienen en:
http://www.martinfowler.com/articles/continuous
Integration.html

Extreme Programming, de la Universidad de

San Francisco
Lo tienen en:
http://www.dccia.ua.es/dccia/inf/asignaturas/MA
DS/lecturas/04a_2_KentBeck_ExtremeProgrammi
ngCh1.pdf
46

2c2014

Siempre conviene que los programas se

ejecuten lo ms rpido posible
La razn principal para no repetir cdigo es
evitar escribir lo mismo dos veces
El cdigo se lee muchas ms veces que las
que se escribe
Antes de agregar un comentario para aclarar,
debera tratar de aclarar el cdigo
Al programar una clase, conviene prever todo
lo que se vaya a necesitar, para incluirlo
desde el principio

Code Complete, Steve McConnell

Captulos 6 a 8, 10 a 13, 14 a 16, 18 a 19: buena parte
del libro

No est en la Web ni en biblioteca

48

2c2014

Temas varios de POO

POO en lenguajes de tipos estticos
Repaso
Primer parcial

49

2c2014