Jesús Jiménez on Team System

Crossposting de www.teamsystem.es

September 2008 - Artículos

Diccionarios para el Análisis estático de código (II)

En el post anterior habíamos visto la estructura de un diccionario personalizado para el Análisis estático de código, pero en la mayoría de los casos puede llegar a ser un auténtico incordio tener que crearlo sin ningún tipo de ayuda, ya que se trata de un fichero Xml sin más. Una de las cosas que podemos hacer en Visual Studio es tener referenciados una lista de esquemas Xsd que nos aportan intellisense a la edición de los ficheros, así que basándonos en el fichero de diccionario que acompaña a Visual Studio vamos a generar un Xsd para que nos ayude en la edición de este tipo de archivos. Para generar un Xsd, tan solo tenemos que abrir el fichero Xml en Visual Studio e irnos al menú XML y seleccionar la opción Generate Schema. Este esquema nos servirá como base y con unas pequeñas modificaciones en los números de ocurrencias de los nodos y añadiendo el "Target Namespace" ya lo tendremos listo para utilizar. Como yo ya lo tengo hecho, lo he colgado para que lo podáis descargar directamente. (CodeAnalysisDictionary.xsd)


DiccionariosPersonalizados - Imagen 2


Una vez hemos creado el esquema lo único que tenemos que hacer para dar soporte a la edición de los ficheros de diccionarios es agregar el esquema generado a la lista de esquemas de Visual Studio desde la opción de menú "XML -> Schemas..." y veremos como ya nos aparece en la lista y como tiene el Target Namespace que le hemos asignado: "http://microsoft.com/schemas/VisualStudio/CodeAnalysis".


DiccionariosPersonalizados - Imagen 3


Y por último, ya solo nos quedaría crear un fichero Xml, poner el valor "http://microsoft.com/schemas/VisualStudio/CodeAnalysis" al atributo "xmlns" del nodo raíz y Violá! ya tenemos intellisense para la edición de nuestros ficheros de diccionarios.


DiccionariosPersonalizados - Imagen 4 


Por último, y para no extenderme mucho más, solo comentaros que una vez tengamos creado nuestro fichero Xml con todos los términos, no es necesario que lo copiemos a cada uno de los proyecto, lo cual nos complicaría un poco el tema del mantenimiento en caso de que quisiésemos añadir nuevos términos al fichero, por lo que una de las soluciones para este caso pasa por poner el fichero Xml a nivel de solución y añadir el fichero a cada proyecto, pero no como un fichero físico, sino como un link al fichero, para solo tener un fichero y que sea fácil de mantener.


DiccionariosPersonalizados - Imagen 5


Y con esto concluye este segundo post dedicado a la creación y uso de diccionarios personalizados para el Análisis estático de código, espero que os sea de ayuda.


teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?
Diccionarios para el Análisis de estático de código (I)

Una de las mejoras que incluye Visual Studio Team System 2008 es el soporte para diccionarios propios en cuanto a la ejecución de las reglas de análisis de código estático se refiere. A pesar de que es una de las funcionalidades que aparece en la mayoría de las listas de nuevas características del producto no es del todo fácil encontrar información detallada acerca de como funciona.

Solo para refrescar un poco la memoria, os comento que el Análisis estático de código, es una funcionalidad que ofrece Visual Studio Team System desde la versión 2005 y que antes podíamos utilizar desde una herramienta externa llamada FxCop. Esta funcionalidad nos permite definir un conjunto de reglas que serán verificadas sobre nuestro código y que varían en cuanto a objetivo. Podemos encontrar reglas relacionadas con el rendimiento, el diseño de nuestras APIs, la portabilidad de nuestro código, mantenibilidad o el caso sobre el que me centraré en esta entrada, el nombrado de los elementos públicos de nuestro código, ya sean interfaces, clases, métodos o propiedades.

Visual Studio Team System viene acompañado de una serie de reglas de nombrado que podemos activar a voluntad y que van desde sugerirnos no utilizar guiones bajos o el correcto uso de mayúsculas y minúsculas, hasta que no usemos variables en los métodos con el mismo nombre que los miembros de una clase. Pero si prestamos atención a las reglas de nombrado (Naming Rules), estas nos sugieren muchas cosas relacionadas con los nombres que usamos para los elementos públicos de nuestro código y se basa en el diccionario de palabras de Word para realizar el análisis, aunque no es necesario tener Word instalado ya que dentro de la carpeta del Análisis estático de código viene incluido ya el diccionario. Sin embargo para los casos en los que este diccionario no sea suficiente se nos permite tener un diccionario personalizado de palabras contra el que el motor de Análisis estático de código realizará las comprobaciones necesarias.

Para añadir un diccionario personalizado lo único que tenemos que hacer es agregar un fichero Xml a nuestro proyecto y cambiar el valor de la propiedad Build Action del fichero y ponerlo a CodeAnalysisDictionary, de esta forma cuando se ejecute el análisis estático de código se verificarán la palabras contra el diccionario que acabamos de crear.


DiccionariosPersonalizados - Imagen 1


El fichero Xml tiene una estructura determinada y en él se nos permite añadir una lista de palabras validas, no validas, palabras en desuso y su alternativa actual, una lista de palabras compuestas, una lista de excepciones para palabras compuestas y por ultimo una lista de excepciones para acrónimos de palabras, aunque veremos cada uno de los puntos en detalle. Si queréis ver un fichero Xml completo bien formado y documentado os recomiendo que vayáis a la ruta "C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop" donde podéis encontrar un fichero llamado "CustomDictionary.xml" que viene con el propio Visual Studio. A continuación os describo cada unos de los tipos de listas que podemos encontrar dentro de este fichero:

  • Palabras reconocidas: Lista de palabras que a pesar de no estar en el diccionario interno no provocarán un error del tipo CA1704. Esta lista de palabras no es sensible a mayúsculas y minúsculas y debemos evitar añadir palabras compuestas en esta lista.
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Words>
    <
    Recognized>
    <
    Word>accessor</Word>
    <
    Word>accessors</Word>
    <
    Word>acos</Word>
    ...
    <Word>xsi</Word>
    <
    Word>xsl</Word>
    <
    Word>xslt</Word>
    </
    Recognized>
    </
    Words>
    </
    Dictionary>
  • Palabras no reconocidas: Lista de palabras que a pesar de estar incluidas en el diccionario se quiere evitar su uso. Estas palabras, al igual que las reconocidas, no son sensibles a mayúsculas y minúsculas y debemos evitar introducir palabras en desuso en esta lista. En caso de que usemos alguna de las palabras incluidas en esta lista provocaremos que la reglas CA1704 genere un Warning o un Error en base a nuestra configuración.
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Words>
    <
    Unrecognized>
    <
    Word>cb</Word>
    <
    Word>ch</Word>
    <
    Word>gt</Word>
    <
    Word>idx</Word>
    ...
    <Word>tw</Word>
    <
    Word>val</Word>
    </
    Unrecognized>
    </
    Words>
    </
    Dictionary>
  • Términos en desuso: La lista de términos en desuso, como cabe esperar, contiene una lista de palabras que no deberían usarse, pero además prove de una palabra alternativa que se debería usar. En caso de que una de las palabras de la lista este en nuestro código y sea de visibilidad pública hará que la regla CA1726 no sea valida. Los términos de esta lista no son sensibles a mayúsculas y minúsculas, pero la palabra alternativa sugerida debería tener una nomenclatura Pascal-Case y en caso de que no tengamos palabra sugerida simplemente podremos dejarla en blanco.
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Words>
    <
    Deprecated>
    <
    Term PreferredAlternate="EnterpriseServices">complus</Term>
    <
    Term PreferredAlternate="Canceled">cancelled</Term>
    <
    Term PreferredAlternate="Indexes">indices</Term>
    <
    Term PreferredAlternate="LogOn">login</Term>
    <
    Term PreferredAlternate="LogOff">logout</Term>
    <
    Term PreferredAlternate="SignIn">signon</Term>
    <
    Term PreferredAlternate="SignOut">signoff</Term>
    <
    Term PreferredAlternate="">flag</Term>
    <
    Term PreferredAlternate="">flags</Term>
    </
    Deprecated>
    </
    Words>
    </
    Dictionary>
  • Palabras compuestas: La lista de palabras compuestas y la alternativa asociada es usada por la regla CA1702 y el motivo de esta lista es que aun siendo palabras compuestas existen en el diccionario como palabras únicas pero sin embargo deberían ser usadas como dos palabras con el correspondiente uso de mayúsculas y minúsculas. Por ejemplo la palabra "Filename" existe en el diccionario, pero el uso correcto tratándose de código debería ser "FileName". Cualquier palabra que se encuentre en esta lista es automaticamente añadida a la lista de palabras DiscreteExceptions que veremos a continuación, ya que si no estuviesen añadidas nunca llegarían a generar un error y no se podría sugerir la alternativa correspondiente.
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Words>
    <
    Compound>
    <
    Term CompoundAlternate="AutoScrolls">autoscrolls</Term>
    <
    Term CompoundAlternate="AutoComplete">autocomplete</Term>
    <
    Term CompoundAlternate="AutoCompletes">autocompletes</Term>
    <
    Term CompoundAlternate="AutoSave">autosave</Term>
    <
    Term CompoundAlternate="AutoSaves">autosaves</Term>
    <
    Term CompoundAlternate="JavaScript">javascript</Term>
    <
    Term CompoundAlternate="JScript">jscript</Term>
    </
    Compound>
    </
    Words>
    </
    Dictionary>
  • Excepciones discretas: Como he comentado anteriormente, en esta lista se encuentran las palabras que a pesar de estar en el diccionario son palabras compuestas y dado que las listas no diferencian entre mayúsculas y minúsculas, se añaden en esta lista las palabras para que la regla CA1702 no genere un falso positivo y sugiera al usuario cambiar la "AutoComplete" por la palabra "AutoComplete".
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Words>
    <
    DiscreteExceptions>
    <
    Term>onset</Term>
    <
    Term>inset</Term>
    <
    Term>byname</Term>
    <
    Term>setout</Term>
    <
    Term>countertype</Term>
    </
    DiscreteExceptions>
    </
    Words>
    </
    Dictionary>
  • Acrónimos: Por último, si bien las listas anteriores eran listas de palabras, esta lista es de acrónimos. En ella incluiremos abreviaturas que por un motivo u otro no deban seguir las reglas de nombrado estándares, como por ejemplo el acrónimo del número matemático "Pi", que según los estándares de nombrado al ser de dos letras debería ir en mayúsculas, como "IO" por ejemplo.
    <?xml version="1.0" encoding="utf-8" ?>
    <
    Dictionary>
    <
    Acronyms>
    <
    CasingExceptions>
    <
    Acronym>Pi</Acronym>
    <
    Acronym>Na</Acronym> <!-- NaN -->
    <
    Acronym>NESW</Acronym> <!-- North East South West -->
    <
    Acronym>NWSE</Acronym> <!-- North West South East -->
    </
    CasingExceptions>
    </
    Acronyms>
    </
    Dictionary>

Creo que con esto os podéis hacer una idea de la potencia que tienen estos diccionarios personalizados pero como aún me quedan algunas cosas que contar que os pueden resultar interesantes he decidido hacer una segunda parte de este post donde hablaré de como compartir un diccionario entre proyectos y de como dar soporte a la edición de estos ficheros.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?
Evento en Mad.NUG

El jueves de la  semana pasada participe como ponente en un evento de Mad.NUG y quería agradecer a todos los que fuisteis vuestra asistencia. La verdad es que a pesar de estar algo nervioso al principio creo que conseguí transmitir lo que pretendía. Del evento surgieron algunos temas que me gustaría comentar, pero no antes sin dejaros por aquí el enlace a la presentación que hice: Gestión del código fuente con Visual Studio Team System 2008

En primer lugar, uno de los comentarios que me hicieron fue que todo lo que enseñé estaba muy bien, pero que en el momento de tener que hacer una demostración a quien tiene la capacidad de decidir económicamente si se implanta el producto o no, harían falta entornos ya montados que pudiesen usarse. A pesar de que al final de la presentación comente qué había utilizado para realizar las demostraciones, no dije que el servidor de Team Foundation Server 2008 que utilice, es una máquina virtual que Microsoft tiene disponible para ser descargada en MSDN Download Center en la siguiente url: http://go.microsoft.com/?linkid=8048142

Esta máquina virtual esta montada sobre un Windows 2003 EE SP2 y viene con Visual Studio Team Suite 2008, Team Foundation Server 2008, Office 2007 SP1, Team Explorer 2008, Visual Studio 2005 y todos los prerequisitos de Team Foundation Server (SPS y SQL Server 2005). Además también esta disponible otra máquina virtual solo con Team Foundation Server 2008 y Team Explorer únicamente, ya que la anterior ocupa unos 5GB, lo cual puede resultar algo lento de descargar. Podéis descargar esta máquina virtual algo más reducida desde la siguiente url: http://go.microsoft.com/?linkid=8048143  

Otra de las cosas que me comentaron fue como se podría afrontar una estrategia de Branching si uno de los proyectos fuese de tipo Web Application, que al hacer Branching y tener varias veces el mismo proyecto en un mismo equipo causaría problemas con los sitios Web o directorios virtuales de nuestro servidor IIS local. Tras indagar un poco y con la ayuda de Luis Fraile (vamos él ha sido quien ha dado con el comportamiento en estos casos) vimos que no hay ningún problema en este escenario. Al abrir el sitio web de un Branch, si el sitio Web ya existe en el IIS te da la opción de sobrescribir el contenido del mismo o de crear uno nuevo, pero como me parece un tema muy interesante voy a escribir una entrada en los próximos días al respecto, explicando de una forma más detallada el proceso.

En definitiva, muchas gracias a todos los asistentes por venir y por supuesto a Mad.NUG por dejarme compartir las cosas que voy aprendiendo sobre Team System.

 

Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?
Posted: 24/9/2008 9:08 por Gsus
Archivado en: ,
Presentación de nuevo blog

Hola a todos!

Mi nombre es Jesús Jiménez y hace ya algún tiempo que estoy dedicando mis esfuerzos para con la comunidad escribiendo y haciendo algún evento sobre temas relacionados con Team System. Actualmente mantengo un sitio web (www.teamsystem.es) dedicado a dicho producto de Microsoft y Rodrigo (al que estoy enormemente agradecido) me ha invitado a hacer crossposting de lo que voy publicando allí en un nuevo blog, aquí en Geeks.

Por ahora, poco más, solo deciros que espero que los contenidos sean de vuestro agrado y que estoy a vuestra disposición para cualquier cosa que necesitéis de mi.

 

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?
Posted: 24/9/2008 0:35 por Gsus |