• No sólo software que funciona,
  si no también software bien hecho.
  
• No sólo que responda a cambios,
  si no también que añada valor de forma continuada.
• No sólo individuos e interacciones,
  si no también una comunidad de profesionales.
• No sólo colaboración con el cliente,
  si no también una asociación productiva.

ESCRIBIR Código:

LA ÚNICA PARTE DEL PROCESO
DE DESARROLLO de software
 QUE NO TE PUEDES SALTAR

ALGUNAS DEFINICIONES:

• El código limpio se lee como prosa bien escrita
  

• El código limpio puede ser leído y mejorado
  por un desarrollador distinto de su autor original.
  
• Tiene tests unitarios y de aceptación.
• Tiene nombres con significado.
• Proporciona una forma de hacer las cosas en lugar
  de muchas alternativas.

• El código limpio parece estar hecho
  por alguien a quien le importa.

1. Pasa todos los tests
2. No tiene duplicidades
3. Expresa las ideas de diseño del sistema
4. Minimiza el número de entidades
   como clases, métodos y similares

• Sabes que estás trabajando con código limpio
  cuando cada rutina que lees resulta ser como lo 
  que esperabas encontrarte.
• Cuando parece que el lenguaje fue hecho para
  el problema que resuelve el código.

• ¿por qué existe?
• ¿qué hace?
• ¿cómo se usa?

• iContador
• arrNums
• bOcupado

• Deberían ser nombres y no verbos
• Evitar palabras ambiguas como "Manager",
  "Gestor", "Procesador", "Controller", "Data",
  "Info"

• Deben ser un verbo
• Y en castellano además es bueno
  que sea imperativo
• En el caso de constructores, mejor 
  que sobrecargar es usar métodos estáticos
  de factoría.

• Reusar el nombre de una clase dentro
  de una propiedad: Contacto.ContactoNombre
  
• Prefijar las clases con el nombre de una aplicación,
  para eso están los namespaces/packages.

• Consistencia en toda la aplicación.
• Evita que una palabra tenga varios significados.
• Evita usar varias palabras para lo mismo.

• Utiliza la semántica del ámbito de negocio
  de la aplicación: ¿que palabras usa tu cliente?
• Las términos usados deben coincidir
  con la forma en que los usuarios verbalizan 
  los problemas.

var calculadoras = {};

calculadoras.COMISIONISTA = calculaComisiones();
calculadoras.ASALARIADO = calculaSalario();
calculadoras.FREELANCE = calculaPagoPorHoras();

function calculaPaga(empleado) {
    return calculadoras[empleado.type](empleado);
}

    

• Sin miedo a los nombres largos.
• Mejor un nombre largo y claro
  que corto y enigmático.
• Mejor un nombre largo y claro
  que un comentario.
• Utiliza un estilo que facilite la lectura.
• Sin pasarse:

• Ninguno: bueno..
• Uno (función monádica): BIEN, fácil de concatenar.
• Dos (función diádica): humm... ok
• Tres (función triádica): hummmmmm..... ¿estas seguo?
• Más de tres: Refactoriza

• ¿Se entienden? 
  .render(true)
  vs
  .renderSuite()
  .renderSingleTest()

• Mejor programación funcional.
• Los efectos secundarios
  generan acoplamientos.
• Si no queda más remedio, que quede
  explicitado:
  .compruebaClaveEIniciaSesion()

• hacer algo
• consultar algo
• pero no ambas cosas

• Comentarios legales
• Comentarios informativos (por ejemplo,
  referenciando documentos normativos
  sobre el cálculo de el DC de un CCC)
• Explicando intenciones
• Comentando APIs públicas

• Mascullando
• Redundantes: RUIDOOOO
• Que conducen a engaño
  (TooMuchCopyPasteException)
• Comentando código complicado:
  reescribe el código!!!
• Código comentado: ¿no tienes control de versiones?
• Diario: ¿no tienes control de versiones???? 
• Marcas personalizadas: porque el cierre
  del bucle está muy lejos?? refactoriza!
• Documentación de métodos privados???

• Separación de bloques
• Bloques compactos

• Acerca conceptos relacionados
• Una función que invoque a otra: acércalas
• El llamador por encima del llamado (excepción: 
  JavaScript que pasa JSLint)
• Variables declaradas cerca de donde se usan
• Variables de instancia al principio de la clase

• Líneas cortas
• Una acción por línea
• Indentación, informa de jerarquía

• En lenguaje procedimental es más fácil
   añadir funcionalidad sin afectar a las
  estructuras. En OO, es fácil añadir nuevas
  clases sin cambiar las funciones.
  
  
• En lenguaje procedimental es difícil añadir
  estructuras, pues afecta a todas las funciones.
  En OO, es más difícil añadir funciones porque
  todas las clases se ven afectadas.

• Limpio
• Un concepto por test
• Una afirmación por test
• Tres pasos para un test:
  

1. Prepara el escenario
2. Ejecuta el código
3. Comprueba el resultado