My C# Style Sheet

Abstract

This is my own style sheet about C#.

To prepare this document, I have used the help file of StyleCop v4.5, the Juval Lowy’s recommendations and my own experience with .NET applications.

Note that this document is a personal document that I have used succesfully in the last years, and with this guide you will be prepared to generate the chm help file of the project with SandCastle.

I know that each software team has their own particular form to apply their naming code. Here is my own manner to do it.

I hope that helps.

Introducción

Llevo ya algo más de 10 años programando en .NET (nunca son suficientes).

Antes de .NET estuve «trasteando» con diferentes lenguajes de programación (C, C++, Clipper, Fortran, Cobol, SmallTalk, Pascal, Java,…) pero por encima de ellos, uno sobre el que guardo un especial cariño… VB.

Sin embargo, y antes de eso, en mi Universidad no me enseñaron a programar bien… sí, cierto… mucho enfoque de gestión, dirección de empresa, marketing, etc… pero programación,… lo que se dice programación, más bien «null«.

Vicios adquiridos

Así que os podéis imaginar en qué se convierte lo que antes comentaba… si apenas me enseña nadie a programar y lo hago de forma autodidacta, eso significa que uno sabe hacer primero un «Hello World«, una pequeña agenda de texto o editor de texto después, y finalmente una aplicación de base de datos que lo único que hace es mantener una agenda de teléfonos, cumpleaños y direcciones… y a partir de ahí todo lo demás, pero… ¿sabemos realmente programar?.

Si conseguimos nuestros objetivos y la aplicación funciona, pero sabemos que eso no es suficiente, es decir, sabemos programa a base de lo que «Dios buenamente me dió a entender«, sin mucha organización y con muchos (muchísimos) vicios adquiridos.

Renovar o morir

No obstante, ya conocemos la frase que todo geek que se precie debe tener en su mente siempre… renovar o morir, así que cuando apareció .NET me embarqué a dicha plataforma, su modelo de programación, y decidí renovar mis conocimientos sobre programación (que no eran muchos) de forma que pudiera aprender a hacer las cosas lo mejor posible.

Esa curva es tan amplia y tan grande que nunca dejas de aprender a hacer las cosas de una manera u otra.

Y embarcado en esa curva de aprendizaje (y muchas más cosas obviamente), he estado trabajando en los últimos años en diferentes empresas.

En todas ellas he visto diferentes formas de hacer las cosas (a veces mejor y a veces peor, con sus pros y sus contras), pero siempre me ha pasado lo mismo cuando llego a una empresa de nuevas… ¿qué nomenclatura utiliza?.

Nomenclatura como puerta de entrada hacia la calidad de codificación

Una cosa sí tengo clara, y es que cuando codificamos, estamos «obligados» a utilizar una nomenclatura de codificación general que nos permita a todos entendernos.

Hablando de DDD, existe un término muy importante que siempre tenemos en cuenta (y no es nuevo, existe de siempre incluso obviamente antes de la existencia de DDD) y que se refiere al lenguaje ubicuo.

A la hora de programar, también debemos intentar utilizar un «lenguaje ubicuo«. La importancia de que todo el código se escriba de una forma homogénea es fundamental, ya que aporta calidad, claridad y facilita la localización y mantenimiento del código de una aplicación (entre otras cosas).

Sirva como ejemplo de todo esto que hoy Pedro está trabajando con el código, pero mañana Pedro se va de vacaciones y María debe trabajar sí o sí con su código. Si María codifica al 99% (el 100% es muy complicado alcanzarlo) de la misma manera, María entenderá lo que Pedro ha hecho y podrá continuar su trabajo, prácticamente como si Pedro fuera el que estuviera codificando (con sus lógicas diferencias claro está).

Si dentro de tres años Juan llega a la empresa y tanto Pedro como María ya no están en la compañía, le será relativamente sencillo ponerse a trabajar con el código (aquí deberíamos extendernos mucho más sobre lo de «relativamente sencillo«, pero esto es para otro día).

Lo que he comentado anteriormente es siempre y cuando Pedro, María y Juan utilicen el mismo documento de nomenclatura global, el mismo lenguaje ubicuo, las mismas reglas y formas de hacer las cosas.

De esta «forma» de trabajar depende la calidad de codificación.

Existen más mecanismos que aportan calidad a la codificación (no es momento de enumerarlos ahora mismo), pero permitidme que exprese que este es para mí el punto inicial y principal que debemos cumplir todos los que nos dedicamos a esto de la codificación.

Siempre con lo mismo

Y aquí es donde me debato, que siempre que llego a un sitio nuevo y debo actuar como arquitecto, responsable del proyecto o con un rol de responsabilidad, me veo inmerso en la misma problemática de siempre una y otra vez… «hay que hacer un documento de nomenclatura«.

Y ya un poco cansado con esto, que se repite una y otra vez en mi recorrido profesional como si del día de la marmota fuera, me he visto animado a hacer una lista de atajos que sirva de apoyo para los programadores, para que utilicen ese lenguaje ubicuo del que hago mención en esta entrada.

My C# Style Sheet

En mi caso, y pese a mi querido VB, he creado un documento con atajos para C#.

Son prácticamente aplicables a VB, pero el documento que he creado está pensado para C# y hay pequeñas puntualizaciones que no aplican sobre VB o aplicarían de otra manera distinta.

Se trata de un documento de nomenclatura y codificación que he hecho basado en los siguientes puntos:

• StyleCop v4.5
• Recomendaciones y nomenclatura de Juval Lowy
• Mi propia experiencia (como no)

Quiero que quede muy claro, que es un documento basado en mi personal punto de vista y teniendo en cuenta en más del 95% las reglas de StyleCop.

El documento lo he generado porque no es lo mismo dar a un programador un documento de más de 20 páginas sobre las reglas de codificación y nomenclatura que condensarlo en un pequeño documento de 2 páginas a modo resumen de cómo codificar y que todo programador puede tener encima de la mesa para consultarlo ante una duda puntual.

En el documento indico incluso las reglas de StyleCop que dejo fuera del análisis de código realizado con Visual Studio 2010 teniendo en cuenta que el código lo paso revisando todas las reglas de codificación de StyleCop.

Como todas las cosas, seguro que hay personas y por lo tanto opiniones que no están muy de acuerdo con algunos de los planteamientos que pongo aquí, pero a mí siempre me ha dado un excelente resultado escribir así y trataré de no cambiar esta manera de hacer las cosas.

Ni que decir que el código escrito así me permite incluso generar el documento de ayuda (chm) del proyecto con SandCastle como herramienta.

Descarga / Download

Pongo por aquí los atajos (en inglés) para que los descarguen y utilicen todas las personas que quieran (formato pdf [128 Kb] y xps [232 Kb]).

Acceder a los documentos aquí.

Access here to the documents (pdf and xps format).

Espero que le sirva a más de uno.