Organización del código y Visual Studio Column Guides

Todos sabemos o deberíamos saber a estas alturas que escribir código es una tarea de creatividad, y que cada desarrollo es diferente de cualquier otro que hayamos hecho previamente.
Existen patrones de coincidencia y parecidos razonables, pero nunca un proyecto es y será igual a otro.

Sin embargo, he tenido la fortuna de trabajar en varias empresas y en prácticamente todas me he encontrado el mismo problema o patrón de comportamiento que daría a una entrada más extensa que esta.
La dirección quiere desarrollar ideas, procesos, aplicaciones, utilidades,… de forma ágil y rápida. Ok hasta aquí, pero el problema principal reside en lo que se entiende por rápido y ágil.
Muchas empresas entienden por rápido y ágil que el mero hecho de escribir código es algo trivial, repetitivo y sin mucho más fundamento. Es decir, el programador es lo más parecido a una máquina.

Esto me recuerda indudablemente a una entrada de Rodrigo Corral que escribió ya hace algún tiempo en su blog.

Admito que yo mismo me he hecho mis propios Frameworks y herramientas que me permitan ahorrar tiempo y me genere automáticamente algunas porciones o partes de código que siempre empleo en todos los proyectos, pero no todo, más que nada porque dada la particularidad de cada proyecto, hacerlo de forma general es completamente imposible (al menos de momento).

El caso es que ante esto y Dios mediante… porque sino me temo que los informáticos tendremos los días contados, tenemos que tener en cuenta diferentes factores y aspectos al codificar y ser creativos. Factores que nos faciliten la codificación para interpretarla adecuadamente.

Así, cuando escribimos código se recomienda ser organizados y ordenados.
El código no es para quién lo escribe, sino para quién lo lee.
Si eres programador y tienes la suerte de que tu código lo vas a leer y mantener sólo y siempre tú, felicidades, pero en el 99,99% de las empresas y organizaciones esto no suele ser así.
Ante esto, siempre que un programador hace frente a una porción de código de otro programador, incluso y aunque sea su mejor amigo, tenderá a pensar que él lo hubiera hecho mejor porque si de algo presumimos los programadores es de pensar siempre que nosotros mismos lo hacemos mejor que otro programador. Créeme que hay pocos que se libren de este pensamiento.

Por esa razón y tratando de minimizar todos estos aspectos, y entre ellos el de creerse mejor que otro, muchas empresas que comienzan un desarrollo desde cero lo primero que hacen es crearse una serie de documentos, guías o patrones que deberán ser utilizados a lo largo de todo el proyecto.
Estos documentos no tratan de fastidiar al programador haciéndole perder el tiempo leyendo una guía de buenas prácticas, sino simplemente de crear una línea de trabajo homogénea a todo el equipo que permita a todo el mundo hablar prácticamente el mismo dialecto o idioma.

Si seguimos estas pautas, estaremos dotando al código de «cierta» calidad en cuanto a su comprensión lectora y su posterior mantenimiento.
Otra cosa y capítulo aparte serían las pruebas unitarias y las pruebas funcionales, pero esto es otro tema que prefiero no mentar ahora mismo para no desviarme demasiado.

El caso es que cuando nos sentamos frente a la pantalla del ordenador y arrancamos Visual Studio para empezar a codificar, debemos tener muy claras estas pautas, y cualquier ayuda es bienvenida.

Por esa razón, en primer lugar he querido hacer unos pequeños comentarios que nos hagan meditar, reflexionar y pensar en qué punto estamos cada uno y si estamos organizando nuestro código de forma correcta o no, y en segundo lugar, apoyarnos en el entorno de desarrollo para que nos ayude a ser un poco más organizados.

De hecho, una de las características ocultas de Visual Studio es la posibilidad de crear líneas verticales de puntos en el editor del entorno, más conocidas como Column Guides.

Estas líneas nos ayudarán a mantener una guía de codificación muy concreta que deberemos crearnos previamente y que nos permita escribir el código de forma ordenada.

Pero lo mejor es siempre ir a los hechos y dejarnos de palabrerías.

Empezaremos por Visual Studio 2008.

¿Cómo son las Column Guides en Visual Studio 2008?

Lo mejor es ver una imagen.

Observando la imagen vemos que el entorno muestra unas líneas verticales que nos ayudan a escribir nuestro código dentro de un patrón, como aquellos cuadernillos que teníamos cuando empezábamos a estudiar con unas guías en su margen izquierdo y/o derecho que nos servían para no salirnos de ellos.

¿Y cómo habilitar las Column Guides?

De una forma muy sencilla.
Abriremos el registro de Windows y buscaremos la entrada: HKEY_CURRENT_USERSoftwareMicrosoftVisualStudio9.0Text Editor.
Dentro de esa entrada agregaremos una nueva cadena de nombre Guides y de valor RGB(225, 0, 0), 4, 8, 80.

La lectura de este valor es muy sencilla.
Se crearán líneas verticales de color rojo (255,0,0) en la columna 4, 8 y 80.

La columna 80 es empleada de forma estándar. De hecho, Microsoft la usa internamente. Evidentemente, nosotros seguiremos siempre las directrices de los documentos y guías de codificación que hayamos preparado para nuestra empresa, compañía o proyecto concreto.

El resultado de este uso es el que veíamos en la primera imagen con el entorno de Visual Studio 2008 de fondo.

Ahora bien, ¿es válido este truco para otras versiones de Visual Studio?.

La respuesta es sí para todas las anteriores a Visual Studio 2010. La excepción es Visual Studio 2010.

Con Visual Studio 2010 Microsoft ha apartado esta característica del entorno, sin embargo, podemos llevar a cabo esta acción utilizando las Productivity Power Tools, que por otro lado recomiendo instalar.

Si quieres obtener las Productivity Power Tools para Visual Studio 2010, haz clic en este enlace.

Una de las herramientas de este paquete gratuito es el Editor Guidelines que puede ser instalado aparte.

Aún y así, con el mero hecho de descargarse este paquete no vale para tener las líneas verticales dentro de nuestro entorno.

Deberemos ir al registro de Windows y hacer las oportunas modificaciones, exactamente igual que con Visual Studio 2008 o versiones anteriores.

La diferencia con respecto al ejemplo anterior es que en este caso abriremos el registro de Windows y buscaremos la entrada: HKEY_CURRENT_USERSoftwareMicrosoftVisualStudio10.0Text
Editor.

El resultado dentro de Visual Studio 2010 es el que se puede ver en esta otra captura de pantalla:

Sin embargo, en el caso de Visual Studio 2010 y desde el mismo IDE, los menos frikis pueden hacer clic con el botón derecho del ratón y acceder a una opción del menú emergente que nos permitirá agregar y eliminar guidelines y modificar su color.

Espero que esta información te parezca útil.