Ok, lo prometido es deuda, aquí esta la respuesta correcta a Cual es la forma más breve [1] (Fue enviada por Leo Soto a info arroba continuum punto cl)

return x && x.validate() && “x es valido” || “x no es valido”

Justificación:

JavaScript retorna siempre la última evaluación de una expresión que sea verdadera, por ejemplo  “return x” retorna la referencia del objeto “x” si es que “x” apunta a algún lado, de lo contrario retorna false. (Observación: “x” debe haber sido declarada anteriormente, de lo contrario debe usarse “typeof x” que retorna false si x no existe (es null) ).

Por otro lado, si cualquier variable o retorno de método es diferente de 0, undefined o null en una expresión condicional esta es evaluada como verdadero (true).

De ahi que si x no es undefined y además x.validate() es verdadero y “x es valido” (evalua en un objeto String literal), se retorne “x es valido”, pues fue la última expresión verdadera. Si lo anterior resultara en false, entonces el circuito evalua lo que hay despues del OR ( “||” ), que en este caso es “x no es valido” (que de nuevo es un objeto String en notación literal) y como no es null o undefined entonces es verdadero y se retorna el objeto.

Genial no?, al principio parece desconcertante pero al comenzar a escribir código aprovechando características como esta se reduce mucho la cantidad de lineas y el código luce más limpio y fácil de mantener.

Incluso puede hacerse más fácil de leer colocando parentesis para separar el circuito:

return (x && x.validate() && “x es valido”) || “x no es valido”

(Ricardo en una session de “Boardshots prototyping” con un cliente)

“Boardshots prototyping” es un concepto de Continuum que tiene que ver con nuestra metodología ágil de desarrollo.

Se basa en revisar conceptos de diseño de las interfaces visuales con los clientes, donde se discuten temas de usabilidad, persuabilidad y arquitectura de la información.

Tiene excelentes ventajas, y a los clientes les gusta, pues los ayuda a formarse una idea temprana de como lucirá el sistema antes de comenzar la codificación.

Por otra parte, en la mayoría de las ocasiones sirve para detectar cambios en los requerimientos iniciales del software.

El cliente final participa activamente en la definición de las pantallas, conviertiendose en un integrante más del equipo de desarrollo (que también participa en su toalidad de las sessiones).

Es una forma ágil y económica de crear prototipos no funcionales de la interfaz gráfica y de detectar los elementos de usabilidad y persuabilidad que se convertirán en lineas de código a posteriori.

Al terminar las sessión con el cliente, se toman fotos digitales de la pizarra, desde varios ángulos y haciendo zoom de los elementos.

Las fotos digitales se anexan a la minuta de la sessión, se suben al repositorio de fuentes del proyecto[1] (por ejemplo al directorio “/proyecto/trunk/doc/boardshots/20090219/” ), y por último son enviadas al cliente para su archivo.

Enviarlas a los clientes se justifica porque en ocaciones tienen observaciones tardias, que se discuten en nuevas sessiones posteriores de “Boardshots prototyping”.

[1] Usamos subversion como repositorio de fuentes hosteado en nuestro proveedor de “Cloud Computing”.

JavaScript sigue impresionandome (recuerdo los días en que lo negaba como lenguaje, diciendo que era para programadores que no entendían de teoría de POO. Mi pasado me condena).

Se me ocurrío escribir sobre las características del lenguaje mediante test de códigos. La idea es poner un ejemplo de código y esperar respuestas (mediante comentarios), colocando la respuesta una o dos semanas despues, así también podre saber si hay personas que leen el blog periodicamente.

Pues bien, la pregunta es:

Cual es la forma más breve (sintáxticamente) de escribir el siguiente código en JavaScript?

if (x != undefined && x.validate()) {

    return "x es valido";

} else {

  return "x no es valido";

}

Definiciones:

1. La pregunta se refiere a la forma más breve de escribir el código sintácticamente, no en ciclos de CPU (que hoy en día no son un problema).
2. La respuesta la pueden dejar en comentarios del post o enviarla por mail a info arroba continuum punto cl.
3. La respuesta en 15 días.
4. Updated (2009-02-17). Se asume que x está definido previamente ! por tanto descartado el dar un ReferenceError.