Contar Líneas de Código

Nasa Contar líneas de código fuente es una práctica que se viene realizando desde tiempos inmemoriales… vamos desde antes de 1970 más o menos. Por ejemplo, de acuerdo con el Centro Tecnológico de Calidad de Software (Software Assurance Technology Center – SATC) de la NASA:

“El tamaño es una de las formas más antiguas y comunes de medición de software. El tamaño de los módulos es en sí misma un indicador de calidad. El tamaño puede ser medido a través del total de líneas de código, contando todas las líneas; que no correspondan a comentarios y que no esté en blanco, disminuyendo las líneas totales, por el número de espacios en blanco y comentarios, y todas aquellas sentencias ejecutables que se definen por un delimitador dependiente del lenguaje de programación.”

Sin embargo, con el paso del tiempo y medida que nuestra disciplina evolucionaba y maduraba, se determinó que por sí sólo el número de líneas de código en un proyecto de software no es un indicador de la calidad del mismo, o la productividad del trabajo realizado por los desarrolladores, si se podría afirmar que es una métrica confiable del tamaño real del proyecto. Habitualmente es una métrica que combinamos con índices como la Complejidad Ciclomática o el número de clases.

En el mundo de Visual Studio contamos con una funcionalidad denominada Code Metrics la cual nos muestra una serie de estadísticas muy útiles sobre nuestra solución y sus proyectos. Entre estas métricas está la cuenta de líneas de código.

Metrics

Ahora, esta cuenta no es exactamente todas las líneas de código de nuestra solución (o proyecto), sino una cuenta aproximada basada en el código IL generado por la compilación (vamos, más o menos lo que hace la NASA). Éste índice como tal es bastante útil en determinar si un método está haciendo más de lo que debe, pues aún cuando un método tenga cientos de líneas de código físico, la compilación puede hacer que el número de líneas sea radicalmente menos, y si el mismo no baja, puede indicar una pobre o inapropiada mantenibilidad del método.

Cuando necesito conocer las líneas reales de código fuente, su tipo (código, comentario o línea en blanco) y su distribución (SQL, XML, ASP.NET o C#) empleo y recomiendo un pequeño programa llamado CLOC, el cual no requiere instalacieon, es súper fácil de usar y soporta cientos de tecnologías y lenguajes de programación, incluyendo C#, ASP.NET, VB.NET y muchos más.

Count

Entre sus características básicas, me es muy útil que es capaz de reconocer el número de líneas blancas dentro de código, y aquellas que se corresponden a texto de documentación y comentarios, con lo cual se puede obtener métricas, ahora si de la calidad del código, sobre cuanto documentado este puede estar. Por ejemplo, imaginen un código fuente sin ninguna documentación. A través de una aplicación como CLOC podríamos determinar esto y así levantar la correspondiente incidencia.

Otras característica interesante es que se puede obtener un reporte de líneas de código por archivo o por lenguaje.

El reporte puede exportarse a un archivo separado por comas, a XML e incluso en sentencias de SQL que pueden ser útiles para inyectar en una base de datos de reportes de estado y salud del proyecto.

Profesionalmente, al realizar auditorias técnicas complemento el resultado del Code Metrics del Visual Studio con los resultados de CLOC. De esa forma puedo ofrecer una fotografía completa de la mantenibilidad del código versus cuanto está escrito, cuanto es espacio vacío y que tanta documentación podríamos encontrar.

Referencias de Proyectos Dependientes del Modo de Compilación

Una de las cosas que más me gustan de la plataforma .NET y del Visual Studio es la gestión de referencias a otras librerías o entre proyectos dentro de una misma solución. Y ni de que hablar que desde que vio a la luz la plataforma NuGet, el tema de gestión y distribución de estas librerías se ha convertido en todo un paseo por el campo, ya que no es necesario indicar que librerías tiene que tener instalado o descargado los desarrolladores, sino que la solución (apropiadamente configurada) se encargará de recuperar los archivos correspondientes durante la primera compilación de forma automática… toda una maravilla!

Sin embargo, y en particular, al trabajar con librerías de terceras partes o third party libraries que no estén disponibles a través de NuGet, existen diversas estrategias que ya se empleaban desde los principios de .NET. La que personal y profesionalmente considero la más apropiada es la de crear una carpeta Lib en la raíz del directorio que contiene al archivo de solución (.sln) e ir colocando allí los diferentes archivos dll que se van a emplear.

Referencias de Proyectos Dependientes del Modo de Compilación - File System

Ejemplo de un proyecto pequeño y sencillo en .NET con soporte para NuGet. Nótese la carpeta Lib en la raíz del directorio que contiene el archivo de solución (.sln).

La parte final sería agregar el contenido de la carpeta Lib a la solución (a través de las funcionalidades de Add solution’s folder y de Add existing item…) para poder gestionar estas referencias a través del repositorio de versiones que empleemos: TFS, GitHub, SVN, o cualquier otro.

Pero… ¿Qué pasa si la version de librería de terceros que necesitamos emplear debe ser diferente en tiempo de desarrollo que en tiempo de despliegue/producción? ¿Cómo se gestiona una referencia a dos archivos dll diferentes dentro de un mismo proyecto y solución?

En principio no se puede. La referencia es exclusive a un archivo dll y a una versión de éste en específico, lo cual plantea un inconveniente que la mayoría de las personas termina resolviendo a través de dudosas prácticas y aún peores estrategias. Otros directamente culpan al Visual Studio y alegan que en otros IDEs es fácil hacer algo como ésto.

El problema es que esta necesidad es tan poco común que pocas personas en una empresa saben como resolverlo, pero la verdad es que es muy fácil a través del Visual Studio y de MSBUILD.

Solución

Supongamos que necesitamos referenciar una lirabría llamada My.Special.Library en una version especifica cunado compilamos en DEBUG y en una versión diferente cuando compilamos en RELEASE. Los pasos serían los siguientes:

  1. Desde el sistema de archivos navegamos hasta el directorio de la solución, y buscamos el directorio especial Lib.
  2. Dentro de Lib creamos dos (2) nuevos directorios: Debug y Release.
  3. Colocamos en cada nuevo directorio la versión de la libraría de terceros (en nuestro ejemplo My.Special.Library) donde corresponda, tal que la versión que queremos para el modo DEBUG esté en el directorio Debug, y de igual manera para el caso del modo RELEASE.
  4. Es importante desde el Visual Studio crear dos (2) ‘Solution Folders’ dentro del ‘Solution Folder’ de Lib para mapear los directorios Debug y Release así como su contenido para poder gestionarlos a través de nuestro correspondiente sistema de gestión de versiones.
    Referencias de Proyectos Dependientes del Modo de Compilación - Lib
  5. Luego, desde el Visual Studio, seleccionamos el proyecto que queremos trabajar desde el ‘Solutio Explorer’.
  6. Hacemos right-click sobre el proyecto y elegimos la opción de ‘Unload project’.
  7. Una vez que el proyecto a sido descargado, hacemos nuevamente right-click y elegimos la opción de editar el archivo .csproj.
  8. Se nos mostrará el XML que conforma el MSBUILD del proyecto. Allí debemos buscar donde comienzan las inclusions de las referencias en el proyecto, lo cual es fácil de identificar porque son una sucesión de tags Reference.
  9. Debemos colocar la siguientes instrucciones (XML) justo antes del ItemGroup que contiene las referencias:
    <Choose>
        <When Condition="'$(Configuration)'=='Debug'">
          <ItemGroup>
            <Reference Include="My.Special.Library, Version=1.222.2033.0, Culture=neutral, PublicKeyToken=26e441566366f4ab">
               <SpecificVersion>False</SpecificVersion>
              <HintPath>..\Lib\Debug\My.Special.Library.dll</HintPath>
            </Reference>
          </ItemGroup>
        </When>
         <Otherwise>
          <ItemGroup>
            <Reference Include="My.Special.Library, Version=1.342.2035.0, Culture=neutral, PublicKeyToken=26e441566366f4ab">
              <SpecificVersion>False</SpecificVersion>
               <HintPath>..\Lib\Release\My.Special.Library.dll</HintPath>
            </Reference>
          </ItemGroup>
        </Otherwise>
    </Choose> 
    
  10. Salvamos el archivo .csproj.
  11. Hacemos de nuevo right-click sobre el proyecto desde el ‘Solution Explorer’ y ahora elegimos la opción de ‘Reload Project’. Si el Visual Studio nos pregunta para cerrar el archivo .csproj, le contestamos que si.

Y listo, ya tenemos configurado el proyecto para que considerere una versión u otra de la librería de terceros dependiendo del modo de compilación, sin tener que hacer nada más, todo de forma automática y transparente.

Lo más interesante de esta solución es que la referencia se actualiza automáticamente y sin interrupciones en el proyecto que la contenga cuando cambiamos de modos de compilación desde el Visual Studio. Así, si estamos en el modo DEBUG, se estará referenciando a la version 1.222.2033.0, pero si cambiamos a otro modo (digamos RELEASE) automáticamente y sin enterarnos se actualizará la referencia del proyecto para utilizer la version 1.342.2035.0.

Por otro lado, no es estrictamente necesario tener que realizar la selección de una versián u otra si estamos en modo DEBUG o no, ya que como Visual Studio y el compilador de C# soportan variables de compilación, podemos definir nuestras porpias variables y emplear éstas para determiner que libraría y versión referenciar en nuestros proyectos.

Espero que este truco les sea de utilidad.

Evitar la ventana de “Adjuntar Advertencia de Seguridad”

Hoy día ya es casi asumible que todo sistema tendrá en su arquitectura uno o más componentes de servicios, habitualmente servicios web. En la plataforma .NET, los servicios web vienen en muchas formas siendo las dos más habituales los ASMX y los SVC (WCF Web Services).

Resulta que con el Windows 7 y el Visual Studio 2008/2010 cuando trabajamos con referencias a servicios web de WCF nos suele saltar la siguiente ventana al depurar la aplicación:

Particularmente esta ventana no supone nada malo. Es una simple advertencia del sistema operativo en la que nos informa de que un usuario X trata de depurar un proceso Y. El problema es que un proceso normal de desarrollo involucra incontables sesiones de depuración, lo que eventualmente conlleva a odiar esta advertencia…

La solución formal y correcta resulta ser bastante sencilla (más allá de estar tocando el registro de Windows). Hay que seguir los siguientes pasos:

  1. Abrir la cónsola de gestión del IIS (simplemente ejecutar el comando inetmgr).
  2. Posicionarse sobre el grupo de aplicaciones (Application Pool).
  3. Seleccionar el grupo de aplicaciones sobre el cual se ejecuta el componente de servicios web de nuestro sistema.
  4. Con el botón derecho del mouse elige la opción de “Opciones Avanzadas”.
  5. En la ventana que aparece, buscamos el apartado de “Identidad” y hacemos click en el botón con los puntos suspensivos (‘…’).
  6. En la nueva ventana emergente, seleccionamos del desplegable de cuentas integradas la opción de “NetworkService”.
  7. Salimos de estas ventanas, y desde una línea de comando con derechos de administrador ejecutamos un reset del IIS (simplemente ejecutar el comando iisreset).

Y santo remedio. Ahora cuando depuremos una aplicación que emplea referencias a servicios web de WCF o cualquier otra integración con otro sistema al cual deba anexarse el depurador no nos saldrá la advertencia de seguridad.

Como cambiar el navegador por defecto en el Visual Studio… sin perder la cabeza!

Los profesionales que trabajamos con el ecosistema de Microsoft y la plataforma .NET solemos estar más que confirmes con el Internet Explorer (excepto el nefasto Internet Explorer 6); sin embargo la mayoría de las veces cuando trabajamos en proyectos web, nuestros clientes nos exigen soportar más de un navegador.

Parte del proceso de soportar más navegadores que el Internet Explorer es que se necesita probar cada página para garantizar su correcto funcionamiento (a nivel de JavaScript) y apropiado renderizado gráfico (a nivel de imágenes, diagramación, estilos y CSS). Lo ideal sería poder probar las páginas directamente desde el Visual Studio, pero cambiar el navegador por defecto que se ejecuta con cada depuración puede llegar a ser algo… laborioso.

En realidad, cambiar el navegador por defecto en el Visual Studio no es difícil, pero tener que hacerlo cada vez que se quiera probar una página o funcionalidad con tres o cuatro navegadores diferentes, entonces empieza a ser un verdadero dolor en… la cabeza.

Algunas personas encontraron mecanismos para automatizar el proceso a través del Windows PowerShell como por ejemplo Scott Hanselman (@shanselman) en este artículo de su blog.

Fue gracias al trabajo de Scott que la gente de Clarius Consulting creó un add-on para el Visual Studio que agrega una nueva barra al menú con botones que permiten cambiar de forma rápida y sencilla el navegador por defecto con el cual queremos trabajar. Esta barra soporta los más nuevos y usados navegadores a parte de Internet Explorer, como por ejemplo: Opera, Safari, Chrome y Firefox.

Este add-on está disponible aquí. Cabe destacar que este add-on es sólo para el Visual Studio 2005, 2008 y 2010, ya que el nuevo Visual Studio 2012 ya incluye esta maravillosa funcionalidad built-in (incluso siendo capaz de levantar y trabajar con más de un navegador a la vez).

Cuando el reto es soportar más de una versión del Internet Explorer, el tema cambia debido a la limitación que tiene Windows de no permitir que diferentes versiones de su navegador convivan en una misma instancia del sistema operativo. Para esos casos en que tenemos que probar contra diversas versiones del IE, no nos queda otra que emplear máquinas virtuales. La parte positiva es que Microsoft sabe de estos escenarios y pone a disposición de la comunidad de desarrolladores y diseñadores web de forma gratuita máquinas virtuales de Virtual-PC con diferentes configuraciones de sistemas operativos y del navegador Internet Explorer. Estas imágenes están disponibles aquí.

Actualización 02-Agosto-2013

Resulta que Microsoft ha movido el tema de las imágenes de máquinas virtuales a un sitio web especializado en el tema de la creación y gestión de aplicaciones web que sean soportadas por varios navegadores. Las imágenes están disponibles en dicho sitio web: http://www.modern.ie/.

Probando el Visual Studio 2012 Release Candidate

Visual Studio 2012

En estos días salió disponible al público adicto al desarrollo en la plataforma .NET la nueva version del Visual Studio 2012, la cual se puede descargar desde aquí. Esta versión ya no está marcada como Beta, sino como Release Candidate; lo cual significa que los próximos releases no tendrán tantos cambios notables como veremos entre esta versión y la anterior Visual Studio 2011 (o quizás me equivoque).

Lo que me gusto…

Cuando estaba en el colegio, para graduarme tenía que presentar una tesis de grado de tópico científico sobre un tema que me apacionara. Ya desde jóven me atraía la computación/informática, así que con mi amigo Juan Carlos Araujo (@JC_Araujo_S) nos dispusimos a crear una aplicación en Visual Basic 6.0 (que estaba recién salido del horno) para crear un sistema que facilitara a los profesores realizar sus actividades del día a día. Una de las características del sistema que diseñamos era emplear un código de colores que a través de su caracter cognitivo permitirera identificar rápidamente en que estado se encontraba el usuario dentro de la aplicación.

Con Visual Studio 2012 vemos justamente ese enfoque de emplear colores para que se pueda identificar rápidamente (casi subconcientemente) en que estado nos encontramos.

En el mismo tono, me encantó que la gente de Microsoft escuchara a la comunidad de desarrolladores, ya que la versión Beta de 2011 era demasiado opaca, plana, de poco contraste y demasiado monocroma. Con la versión 2012 vemos que la iconografía tiene mejor contraste y mayor colorido, sin romper en mi opinión con la filosofía de METRO UI.

El debugger está muy mejorado, sobre todo para trabajar con JavaScript; cosa que asumo es un esfuerzo por parte de Microsoft de ofrecer un IDE para el desarrollo de METRO Apps que son muy basadas en HTML5 y JavaScript. La ventana de “Callstack” para depurar aplicaciones web está muy mejorada, lo cual se agradece.

Otra cosa que me gusta es que la ventana de “Solution Explorer” ahora ofrece más información sobre las características de los archivos y clases, como sus métodos, propiedades y atributos. Sin embargo creo que necesita trabajarse un poco más antes de la versión final.

Lo que no me gusto…

Una de las cosas que me han chocado es la UX. Como desarrollador, trato de maximizar lo más posible el espacio disponible para el código fuente, lo que significa que la mayoría de las ventanas como el “Toolbox”, “Output”, el “Team Explorer” o el “Solution Explorer” las tengo escondidas (que en VS2010 por ejemplo se ven como pestañas) pero disponibles siempre que pase el mouse por encima. Con esta versión, estas ventanas no se ven como pestañas sino como botones planos, y siempre que quiera ver alguna tengo que hacer click sobre estos; lo que significa que tengo que hacer “más” clicks para ser “productivo”.

Estéticamente me sigue pareciendo muy plano. Está mejor que la versión 2011, sin embargo sigue siendo demasiado homogeneo y siento que eso hace que sea confuso o relentizante encontrar la opción funcional que se busca.

Haz click para ver la imagen más grande.

Otra cosa que me chocó es que los menús están en mayúsculas. Aunque es un enfoque que busca acercar más la UI a la filosofía de METRO UI, creo que no es la mejor desición.

Finalizando…

Esta es una versión de Visual Studio que no podemos perdernos. Una versión histórica que nos mostrará que tan lejos puede llegar un IDE dentro de un nuevo mundo Post-PC, para desarrollar aplicaciones móviles y de tablets bajo los nuevos paradigmas táctiles.

Sin embargo creo que la UI y la UX siguen necesitando una mano más de pintura, un poco más de arte y menos de futurism y color plano.

Mi mejor recomendación, es instalarlo en un Windows 8, que casualmente también tiene una nueva versión de pruebas disponible para descargar aquí, y desde el cual he escrito esta publicación.

Finalmente, la gente de Microsoft nos ha dejado una entrada en sus blogs con un completo listado y descripción de los cambios que encontraremos en esta nueva versión.

Forzar la Desinstalación del Visula Studio 2008

Muchas veces nos encontramos con la situación de que necesitamos agregar o remover un componente de nuestra instalación del VS2008, o simplemente nos queremos deshacer de él. Sin embargo, cuando ejecutamos desde el medio (DVD ó ISO) a través del cual lo instalamos, o desde el ‘Add or Remove Program’ del Control Panel (o su equivalente en Windows Vista/7) nos encontramos con el siguiente mensaje:

La solución final vendría de desinatalar completamente y de forma forzosa el VS2008 empleando la herramienta de auto-desinstalación de Microsoft, la cual puede ejecutarse desde aquí.