Narciso Cerezo

Tecnología y emprendizaje

Mayo del 2004

Herramientas de modelado de Microsoft

La verdad es que estoy muy contento por el hecho de que herramientas como estas vayan a llegar a nuestra comunidad.
Creo que es un buen acercamiento hacia el diseño, hacia la mejora de los procesos de RAD y la calidad del software, y además, alineado con las metodologías ágiles.
Por favor, tómate un rato y lee este post en TheServerSide.NET, y no te olvides de leer los enlaces que pone Dion, merece la pena leerlos.

JetBrains ReSharper

Hay muchos editores y entornos de desarrollo en el mercado. He tenido la oportunidad de probar muchos durante estos años, pero hay uno que me conquistó inmediatamente. Se trata de IntelliJ Idea, del cual puedes bajar una versión de evaluación o mejor aún, participar en el programa EAP (Early Access, Acceso Temprano) y probar la versión en la que trabajan actualmente.
Probablemente hay otros entornos con mejores capacidades para el diseño de interfaces gráficas swing, pero no hay ninguno con las capacidades de edición avanzadas de Idea, ni con su integración con las nuevas tendencias en el desarrollo, tales como el refactoring, ant, JUnit, AspectJ, y muchas otras.
Pero ahora, los chicos de JetBrains nos van a sorprender con otra maravilla, se trata de ReSharper, un plugin para Visual Studio .NET 2003 que aporta una parte de las capacidades de Idea al entorno de Microsoft. De momento, las capacidades son reducidas y está en beta, pero puedes probarlo participando en el EAP.

JetBrains ReSharper

Nomenclatura y estilo (II)

Bueno, vamos con la diversión.

Antes de comenzar he de decir que debes tener una guía de estilo para tu empresa o proyecto, y que esa será tu guía. Hay muchas cosas acerca de las guías de estilo que se pueden considerar subjetivas, y variarán dependiendo del lector.

Pongo un enlace a una guía bastante completa de Philips para C#, que es muy específica de C# pero que tiene muchas cosas aplicables a cualquier lenguaje orientado a objetos. Tengo que decir que no estoy de acuerdo con todos los puntos de esta guía, y que echo de menos algunas explicaciones en ella, aunque es algo razonable teniendo en cuenta de que se trata de una guía impuesta a un grupo de desarrollo, y no una discusión como la que hacemos aquí.
Creo que este documento mezcla conceptos de nomenclatura, formato de código y estilo de código, que son diferentes para mí. Ya he hablado de nomenclatura, y volveré a hacerlo más adelante. El formato de código hace referencia a la apariencia del código, y cómo hacer para que sea más legible, y además es menos específico del lenguaje. El estilo de código por el contrario, se refiere a técnicas de codificación y cómo escribir mejor código. Las tres cosas son esenciales, y en casos concretos como la guía Philips puede tener sentido mezclarlas, pero yo prefiero mantenerlas apartadas (juntas pero no revueltas).

Voy a comenzar hablando sobre el Formato de Código, exponiendo primero las cosas objetivas y explicando su razón. Luego seguiré con las subjetivas, relacionadas fundamentalmente con espacios y longitudes. Por último hablaré sobre el Estilo de Código, dividiéndolo de igual manera.

Debes recordar que este es mi blog y, por tanto, escribo aquí mis propios pensamientos y preferencias, que pueden ser diferentes de los tuyos. Generalmente estoy a cargo de definir todo este tipo de políticas en el trabajo, y de obligar su cumplimiento. Si, obligar; cuando trabajas para una compañía debes seguir sus guías de trabajo, aunque sean diferentes de las tuyas. Cuando estés desarrollando en casa, o dejes la compañía, podrás usar tus propias reglas.

Comencemos.

Declaración de variables
Estoy de acuerdo con la guía en que las variables deben ser declaradas allí donde se usen, en lugar de ponerlas todas juntas al comienzo del método. Esta es una de las capacidades añadidas en C++ respecto a C, y una buena. Si declaras una variable junto al bloque en que se usa estás facilitando el refactoring del código, porque puedes tomar todo el bloque y llevarlo a otro método, por ejemplo; y si resulta que quieres borrar el bloque no corres peligro de dejarte olvidada la variable. Además, al poner la variable junto al bloque en que se usa mejoras la comprensión sobre su cometido.

Bloques de control
De nuevo estoy de acuerdo. Toda sentencia de control (if, while, etc.) debe estar seguida de un bloque de control, aunque esté vacío. A pesar de que C++, C# y java te permiten no utilizar llaves para bloques simples (de una línea) es algo muy propenso a errores: si después añades una línea al bloque, es fácil que olvides poner las llaves, con lo cual el programa compilará pero no funcionará correctamente. Este tipo de errores suelen ser muy difíciles de encontrar.

Usa espacios, no tabuladores
Muchos dirán que esto es algo subjetivo, pero yo digo que no lo es. La razón es simple: los espacios son la única forma de garantizar que la intentación permanece consistente independientemente del sistema. Usualmente, diferentes sistemas muestran los tabuladores de forma distinta, y no sólo aplica a pasar de Windows a Unix, por ejemplo, sino entre diferentes programas en un mismo sistema operativo. La parte subjetiva es cuantos espacios utilizar para la indentación. Yo uso cuatro, pero es subjetivo.

Indentación
Debes usar un estilo de indentación bueno y consistente. Eso es objetivo. El resto del asunto es subjetivo, y creo que haré un post al respecto con mis propias preferencias. La indentación está muy relacionada con la máxima longitud de línea, cosa de la que hablaré en el siguiente post.

Y esto es lo poco que puedo considerar objetivo acerca del Formato de Código.

Philps' C# Coding Guidelines

Nomenclatura y estilo (I)

Por fortuna ya son muchos los que utilizan nomenclaturas y estilos de programación bien definidos. Aún así, durante mi trayectoria profesional, he tenido el dudoso privilegio de toparme con muchos más que no lo hacen.
He de decir que esto no ocurre sólo en ambientes que pudiéramos llamar de bajo perfil tecnológico, sino en empresas de consultoría de primer nivel. Desde mi punto de vista, debido a la contratación indiscriminada de la época .com.
Este es uno de los factores imprescindibles para conseguir código de calidad, primer paso de una cadena en la que aparece el refactoring de Kent Beck y Martin Fowler, y su importancia es mayor cuanto mayor es el proyecto y el equipo.
Durante los incontables años que llevo programando, mi estilo y nomenclatura han ido variando, adaptándose a los entornos y lenguajes, y mejorando con la experiencia adquirida, y tengo claro que seguirán cambiando como algo vivo.
Hoy hablaré sólo de nomenclatura, próximamente seguiremos con el estilo (mucho más interesante), y me centraré en los entornos más extendidos hoy en día: Java y .NET.

Nombres de clase
En este ámbito caen tanto las clases como los interfaces.
Durante bastante tiempo utilicé prefijos para nombrar clases e interfaces, anteponiendo una C o una I, respectivamente. En .NET se utiliza de hecho esta convención para con los interfaces, mientras que en Java no se hace distinción. Personalmente creo que la I no aporta nada y por eso he dejado de utilizarla. No aporta nada porque los interfaces son nuestra cara al exterior (buena práctica: codificar hacia interfaces), y al usuario de nuestros interfaces poco le importa si aquello que usa es un interfaz o una clase, su uso no varía, por tanto la I creo que añade datos innecesarios y con ello empeora el estilo. No obstante, en .NET puede ser recomendable utilizarla para mantener la coherencia con el entorno.
En general, los nombres de clase o interfaz deben constar de una o más palabras representativas, completamente escritas salvo que sean abreviaturas ampliamente extendidas, capitalizadas en su primera letra y sin guiones bajos u otros artefactos entre ellas. Ejemplo: DataObject.
Como extensión, creo que es buena práctica añadir al nombre de clase el patrón de software que representa en caso de representar alguno. Ejemplo: DataObjectFactory.

Nombres de métodos y propiedades públicas
Mi consejo en este sentido es utilizar las normas expuestas en las diferentes guías de estilo de los entornos.
Por ejemplo, en Java el nombre está compuesto de la misma forma que hemos explicado para los nombres de clase, pero con la primera palabra completamente en minúsculas. Ejemplo: provideSomeInfo().
En .NET la nomenclatura es idéntica a la del nombre de clase, siguiendo el ejemplo: ProvideSomeInfo().

Nombres de variables y propiedades privadas o protegidas
La nomenclatura propuesta en Java o .NET es similar, e igual a la propuesta para los métodos y propiedades públicos.
Durante mucho tiempo he empleado mi propia variación de la notación húngara propuesta por Charles Simonyi, fruto de mi herencia de C/C++, pero ciertamente en los lenguajes más puramente orientados a objetos como Java o C# tiene menos sentido y es un tema sobre el que se podría debatir

Algunas normas básicas
Es imprescindible que los nombres sean siempre representativos, y expliquen bien el cometido de un método o variable, no os importe tener que escribir más porque el incremento en la calidad y legibilidad del código os pagará cuando tengáis que revisarlo.
Únicamente puede saltarse la excepción de utilizar nombres genéricos, de una letra, en el caso de contadores enteros usados en bucles, restringiendo estos a los tradicionales en matemáticas: i, j, k, m, n. Y además en este orden suponiendo bucles anidados. Esto último es importante para mantener la coherencia y prevenir errores en zonas muy anidadas (que no deberían ocurrir, pero eso pertenece al estilo).

Closing the Gap, part 2

En la segunda parte de este interesante artículo, Eric Sink nos da unos consejos de inapreciable valor si queremos dedicarnos al desarrollo de software como "pequeños ISV". Para los que no lo sepan, ISV viene del inglés "Independent Software Vendor" o "Proveedor de Sofware Independiente".
Eric nos enseña cómo saber si nuestro producto tiene interés, y como hacerlo llegar al consumidor utilizando los recursos a nuestro alcance, como los blog, donde podemos comunicarnos con nuestros posibles usuarios y conocer sus intereses o inquietudes. La estrategia se basa en dejar que el cliente sea el que lleva el control, el que decide qué compra y cuando lo hace. Sinceramente creo que es un artículo que no debes dejar de leer.

Closing the Gap, Part 2

Inauguración

Sea cual sea la profesión de uno, la vida es un constante aprender. Pero quizás hay dos cosas que nos hacen aprender más aprisa que el resto: los fracasos y los demás.
Los fracasos nos enseñan lecciones muy duras, que pueden llegar a minar nuestra voluntad, pero gracias a ellos somos más sabios y tomamos mejores decisiones, que es de lo que se trata.
Los demás nos enseñan nuevas formas de ver las cosas, y nuevos conocimientos, pero esto no es posible sin una interacción con otros individuos (los fracasos son una experiencia í­ntima y personal). Esa interacción hay que fomentarla cada dí­a, en nuestro trabajo, en nuestra vida personal y, gracias a los blog, ahora podemos extender esa comunicación al mundo entero.
Así­ que ya sabéis cual es mi intención con este blog: enriquecerme (en el terreno intelectual y humano, claro ;-) ).