Estndar codificacin DOTNET

Un estndar de codificacin completo comprende todos los aspectos de la generacin de cdigo. Si bien los programadores deben implementar un estndar de forma prudente, ste debe tender siempre a lo prctico. Un cdigo fuente completo debe reflejar un estilo armonioso, como si un nico programador hubiera escrito todo el cdigo de una sola vez. Al comenzar un proyecto de software, es necesario establecer un estndar de codificacin para asegurarse de que todos los programadores del proyecto trabajen de forma coordinada. Cuando el proyecto de software incorpore cdigo fuente previo, o bien cuando realice el mantenimiento de un sistema de software creado anteriormente, el estndar de codificacin debera establecer cmo operar con la base de cdigo existente. La legibilidad del cdigo fuente repercute directamente en lo bien que un programador comprende un sistema de software. La mantenibilidad del cdigo es la facilidad con que el sistema de software puede modificarse para aadirle nuevas caractersticas, modificar las ya existentes, depurar errores, o mejorar el rendimiento. Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una faceta del desarrollo de software en la que todos los programadores influyen especialmente es en la tcnica de codificacin. El mejor mtodo para asegurarse de que un equipo de programadores mantenga un cdigo de calidad es establecer un estndar de codificacin sobre el que se efectuarn luego revisiones del cdigo de rutinas. Usar tcnicas de codificacin slidas y realizar buenas prcticas de programacin con vistas a generar un cdigo de alta calidad es de gran importancia para la calidad del software y para obtener un buen rendimiento. Adems, si se aplica de forma continuada un estndar de codificacin bien definido, se utilizan tcnicas de programacin apropiadas, y, posteriormente, se efectan revisiones del cdigo de rutinas, caben muchas posibilidades de que un proyecto de software se convierta en un sistema de software fcil de comprender y de mantener. Aunque el propsito principal para llevar a cabo revisiones del cdigo a lo largo de todo el desarrollo es localizar defectos en el mismo, las revisiones tambin pueden afianzar los estndares de codificacin de manera uniforme. La adopcin de un estndar de codificacin slo es viable si se sigue desde el principio hasta el final del proyecto de software. No es prctico, ni prudente, imponer un estndar de codificacin una vez iniciado el trabajo

Las tcnicas de codificacin incorporan muchos aspectos del desarrollo del software. Aunque generalmente no afectan a la funcionalidad de la aplicacin, s contribuyen a una mejor compresin del cdigo fuente. En esta fase se tienen en cuenta todos los tipos de cdigo fuente, incluidos los lenguajes de programacin, de marcado o de consulta. En general una tcnica de codificacin no pretende formar un conjunto inflexible de estndares de codificacin. Ms bien intenta servir de gua en el desarrollo de un estndar de codificacin para un proyecto especfico de software.

GENERALES Para conservar recursos sea muy selectivo en la eleccin del tipo de dato, asegrese que el tamao de una variable no sea excesivamente grande. Por ejemplo en los ciclos for es mejor, en la mayora de las veces utilizar un tipo de dato tipo short que int. Mantenga el tiempo de vida de las variables tan corto como sea posible, esto es muy importante por ejemplo cuando se utiliza un recurso finito como una conexin a una Base de Datos. Mantenga el scope de las variables tan corto como sea posible, esto sirve para evitar confusiones, mejorar la mantenibilidad y adems minimiza la dependencia, es decir si por algn motivo se comete el error de borrar una variable es ms fcil de encontrar el error si esta tiene un scope ms pequeo. Use los procedimientos y variables con un solo propsito. Evite crear procedimientos multipropsito que lleven a cabo una variedad de funciones no relacionadas. Dentro de una clase, evite el uso de variables publicas, en cambio utilice procedimientos y propiedades que accedan a dichas variables (privadas), as provee una capa de encapsulacin y brinda la posibilidad de validar valores de cambio sobre las mismas, antes de manipularlas directamente. Cuando utilice objetos pooled de MTS (Microsoft Transaction Server), adquiera los recursos lo mas tarde posible y librelos lo mas prontocomo sea posible, esto repercute en el manejo de recursos

Use siempre un esquema transaccional como MTS o SQL Server y minimice el scope y la duracin de las transacciones.

Cuando se trabaje en un entorno web distribuido (aldea web), tenga cuidado de almacenar informacin en variables de sesin ASP ya que el estado de sesin es almacenado siempre en una sola maquina, considere mejor almacenar dicha informacin en una base de datos.

No abra conexiones a datos usando credenciales especificas de usuario, ya que estas no podrn ser reutilizadas por el pool de conexiones.

Evite el uso de conversin de tipos o casting ya que esto puede generar resultados imprevistos, sobre todo cuando dos variable estn involucradas en una sentencia, utilice el cast solo en situaciones triviales, cuando este no sea el caso asegure de comentar la razn por la cual lo hizo.

Use siempre rutinas de manejo de excepciones Sea especifico cuando declare objetos que puedan generar colisin, por ejemplo si tiene dos mtodos con el mismo nombre en diferentes namespaces escrbalos con el nombre completo incluyendo el del paquete. Evite el uso de variables en el mbito de aplicacin (web). Use siempre sentencias Select-Case o Switch en lugar de utilizar sentencias ifthen repetitivas. Libere explcitamente las referencias a objeto. (variable = nothing variable = null) Siempre que sea posible utilice polimorfismo en vez de clusulas Switch o Select.

Las tcnicas de codificacin estn divididas en tres secciones: Nombrado Documentacin Interna (Comentarios) Formato

NOMBRADO
El esquema de nombres es una de las ayudas ms importantes para entender el flujo lgico de una aplicacin. Un nombre debe ms bien expresar el "qu" que el "cmo". Si se utiliza un nombre que evite referirse a la implementacin se estar conservando la abstraccin de la estructura ya que la implementacin est sujeta a cambios, de esta manera se describe que hace la estructura y no como lo hace. Por ejemplo es mas claro nombrar un procedimiento de acceso a datos SeleccionarRegistro() que RealizarConsultaSelect(), porque lo que importa (para que otra persona entienda el cdigo) es que se supone que hace el mtodo y no como lo hace. Otra directiva es la de utilizar nombres tan largos como para que se entiendan pero a la vez tan cortos como para que no den informacin irrelevante, por ejemplo es mejor emplearSeleccionarComida() que SeleccionarlaComidadelMenu(). Desde el punto de vista de la programacin, un nombre nico sirve solamente para diferenciar un elemento de otro. Los nombres expresivos funcionan como ayuda para el lector, por eso, es lgico dar nombres que sean fciles de comprender. No obstante, asegrese de que los nombres escogidos sean compatibles con las reglas de cada lenguaje y con los estndares.

Estructuras (namespaces, procedimientos, clases, interfaces y propiedades)

Los nombres de todas las estructuras de cdigo deben ser en espaol.

Los namespaces deben empezar por el nombre de la compaa seguido de la unidad de negocio, el producto o proyecto yla funcionalidad:
Heinsohn.FabricaSw.Papelsa.AccesoaDatos [compaa].[unidad de negocio].[proyecto].[funcionalidad]

El nombre del ensamblado y el namespace root deben ser idnticos El nombre de la clase y el archivo fuente deben ser iguales. No se debe usar la notacin hngara, la cual prefija una abreviatura referente al tipo de objeto: lblAceptar (label), btnOK(Botn), etc. Evite nombres imprecisos que permitan interpretaciones subjetivas, como por ejemplo DefinirEsto(), o bien ytG8 para una variable. Tales nombres contribuyen ms a la ambigedad que a la abstraccin. En la POO es redundante incluir nombres de clases en el nombre de las propiedades de clases, como por ejemplo Rectngulo.RectnguloArea, en su lugar, utilice Rectngulo.Area, pues el nombre de la clase ya contiene dicha informacin. Utilice la tcnica verbo-sustantivo para nombrar procedimientos que ejecuten alguna operacin en un determinado objeto, como por ejemplo CalcularDesperdicio(). Empiece los nombres de clase y propiedades con un nombre, por ejemplo CuentaBancaria, la primera letra de cada palabra debe ser mayscula. En lenguajes que permitan sobrecarga de funciones, todas las sobrecargas deberan llevar a cabo una funcin similar. Para los lenguajes que no permitan la sobrecarga de funciones, establezca una nomenclatura estndar relacionada con funciones similares. Empiece los nombres de interfaz con el prefijo "I", seguido de un nombre o una frase nominal, como IComponente, o con un adjetivo que describa el comportamiento de la interfaz, como IPersistible. No utilice el subrayado_(con

la excepcin de las variables privadas), y utilice lo menos posible las abreviaturas, ya que pueden causar confusiones.

Variables
Las variables miembro se escriben con la primera letra de cada palabra en mayscula a excepcin de las variable miembro privadas. Las Variables internas o de bloque deben ir en minscula. En el caso de las variablesmiembro privadas, se debe utilizar el prefijo m_ sumado al nombre de la variable (m_variable). Es recomendado que las variable booleanas contengan una palabra que describa su estado: puedeEliminarse, esGrande, tieneHijos, etc. Y siempre se debe referir al estado verdadero: tieneCredito en cambio de noTieneCredito Incluso para el caso de una variable de poco uso, que deba aparecer slo en unas cuantas lneas de cdigo, emplee un nombre descriptivo. Utilice nombres de variables de una sola letra, como i o j slo para ndices (ciclos for). No utilice nmeros o cadenas literales, como por ejemplo For i = 1 To 7. En su lugar, emplee constantes con nombre, del tipo For i = 1 To Enumeracion.length para que resulten fciles de mantener y comprender.

Parmetros
Los parmetros siguen el mismo estndar de las variables

Tablas
Cuando ponga nombres a tablas, hgalo en singular. Por ejemplo, use Empleado en lugar de Empleados. Cuando ponga nombre a las columnas de las tablas, no repita el nombre de la tabla; por ejemplo, evite un campo llamado EstudianteApellido de una tabla llamada Estudiante. (Igual que con las propiedades de una clase). No incorpore el tipo de datos en el nombre de una columna.

Microsoft SQL Server No ponga prefijos sp a los procedimientos almacenados, ya que se trata de un prefijo reservado para la identificacin de procedimientos almacenados de sistemas. No ponga prefijos fn_ a las funciones definidas por el usuario, ya que se trata de un prefijo reservado para funciones integradas. No ponga prefijos xp_ a los procedimientos almacenados extendidos, ya que se trata de un prefijo reservado para la identificacin de procedimientos almacenados extendidos. Los nombres de los campos deben empezar por Mayscula.

Varios
Para trminos largos o utilizados con frecuencia, utilice abreviaturas para mantener las longitudes de los nombres dentro un lmite razonable, por ejemplo, "HTML" en lugar de "Lenguaje de marcado de hipertexto". En general, los nombres de variable con ms de 32 caracteres son difciles de leer. Adems, asegrese de que sus abreviaturas sean coherentes a lo largo de toda la aplicacin. Si utiliza indistinta y aleatoriamente "HTML" y "Lenguaje de marcado de hipertexto" en un mismo proyecto, provocar confusin. Minimice el uso de abreviaturas; pero si las emplea, use coherentemente las que haya creado. Una abreviatura slo debe tener un significado y, del mismo modo, a cada palabra abreviada slo debe corresponder una abreviatura. Por ejemplo, si utiliza "min." para abreviar "mnimo", hgalo siempre as, y no use tambin "min." para abreviar "minuto". Cuando nombre un procedimiento que retorne un valor, incluya adems de la accin, la entidad que ser devuelta; LeerArchivo, ConsultarSaldo, ObtenerResumen.

Los archivos y los nombres de carpetas, al igual que los nombres de procedimientos, deben describir claramente su finalidad.

Evite reutilizar nombres para elementos diferentes, como por ejemplo una rutina llamada ProcesoLavado() y una variable iLavado. Evite el uso de caracteres como $ o % No use nombres que sean dependientes del tipo de variable, control o clase en cambio utilice, como ya se dijo, nombres que describan el propsito de la variable , control o propiedad. Evite este comportamiento: void Escribir(double doubleValor), en su lugar utilice void Escribir(double valor).

COMENTARIOS
Existen dos tipos de documentacin de software: externa e interna. La documentacin externa, como por ejemplo las especificaciones, los archivos de ayuda y los documentos de diseo, se debe mantener fuera del cdigo fuente. La documentacin interna est formada por los comentarios que los programadores escriben dentro del cdigo fuente durante la fase de desarrollo. Uno de los problemas de la documentacin de software interna es garantizar que se mantengan y actualicen los comentarios al mismo tiempo que el cdigo fuente. Aunque unos buenos comentarios en el cdigo fuente no tienen ningn valor en el tiempo de ejecucin, resultan valiossimos para un programador que tenga que mantener una parte de software particularmente compleja.

Siga las siguientes pautas para realizar comentarios: Los comentarios deben ser en espaol. Si programa en C#, utilice la funcin de documentacin XML. Cuando modifique el cdigo, mantenga siempre actualizados los comentarios circundantes.

Al principio de cada rutina, resulta til hacer comentarios estndar, repetitivos, que indiquen el propsito de la rutina, las suposiciones y las limitaciones. Un comentario repetitivo podra consistir en una breve introduccin que explicara por qu existe y qu puede hacer.

Evite aadir comentarios al final de una lnea de cdigo, porque lo hacen ms difcil de leer. Sin embargo, los comentarios de final de lnea s son apropiados al anotar declaraciones de variables. En este caso, alinee todos los comentarios de final de lnea en la misma posicin de tabulacin.

Evite los comentarios recargados, como las lneas enteras de asteriscos. En su lugar, utilice espacios para separar los comentarios y el cdigo.

Evite rodear un bloque de comentarios con un marco tipogrfico. Puede resultar agradable, pero es difcil de mantener.

Antes de la implementacin, quite todos los comentarios temporales o innecesarios, para evitar cualquier confusin en la futura fase de mantenimiento.

Si necesita realizar comentarios para explicar una seccin de cdigo compleja, examine el cdigo para decidir si debera volver a escribirlo. Siempre que sea posible, no documente un cdigo malo, vuelva a escribirlo. Aunque, por regla general, no debe sacrificarse el rendimiento para hacer un cdigo ms simple para el usuario, es indispensable un equilibrio entre rendimiento y mantenibilidad.

Use frases completas cuando escriba comentarios. Los comentarios deben aclarar el cdigo, no aadirle ambigedad. Vaya comentando al mismo tiempo que programa, porque probablemente no tenga tiempo de hacerlo ms tarde. Por otro lado, aunque tuviera oportunidad de revisar el cdigo que ha escrito, lo que parece obvio hoy es posible que seis semanas despus no lo sea. Evite comentarios superfluos o inapropiados, como comentarios divertidos al margen. Use los comentarios para explicar el propsito del cdigo. No los use como si fueran traducciones literales.

Para evitar problemas recurrentes, haga siempre comentarios al depurar errores y solucionar problemas de codificacin, especialmente cuando trabaje en equipo.

Haga comentarios en el cdigo que est formado por bucles o bifurcaciones lgicas. Se trata en estos casos de reas clave que ayudarn a los lectores del cdigo fuente.

Realice los comentarios en un estilo uniforme, respetando una puntuacin y estructura coherentes a lo largo de toda la aplicacin.

Separe los comentarios de sus delimitadores mediante espacios. Si respeta estas normas, los comentarios sern ms claros y fciles de localizar si trabaja sin indicaciones de color. Cada declaracin de variable importante debe incluir un comentario en la misma lnea que describa el uso de la variable que se declara. Despus de la secuencia de continuacin de lnea no puede escribirse un comentario en la misma lnea. Todos los comentarios deben estar ortogrficamente bien escritos, una escritura incorrecta demuestra un desarrollo negligente. Evite comentarios que expliquen cosas obvias, en la mayora de las cosas el cdigo debe ser autoexplicativo. Un buen cdigo con buenas prcticas de nombrado no debe ser comentado.

FORMATO
El formato hace que la organizacin lgica del cdigo sea ms clara. Si toma el tiempo de comprobar que el cdigo fuente posee un formato coherente y lgico, les resultar de gran utilidad a usted y a otros programadores que tengan que descifrarlo. Siga las siguientes pautas para establecer el formato: Evite albergarmltiples clases en un solo archivo. Establezca un tamao estndar de sangra (por ejemplo, cuatro espacios o una tabulacin) y selo siempre. Alinee las secciones de cdigo mediante la sangra predeterminada. Use un nico tipo de letra cuando publique versiones impresas del cdigo fuente. Declare una sola variable por lnea (excepto VB). Incluya llaves en las bloques condicionales as sea de una sola sentencia (excepto VB). Agregue los namespaces en orden descendente empezando por los del sistema y terminado por los personalizados o de usuario. Una clase debe estar definida en orden descendente de la siguiente manera: Variables Miembro, Constructores, Enumeraciones, Estructuras o Clases anidadas, Propiedades y por ultimo los Mtodos. La secuencia de declaracin de acuerdo a los modificadores de acceso debe ser la siguiente:

public protected internal private

Asle la interfaz de implementacin utilizando bloques Region.

 Alinee verticalmente las llaves de apertura y cierre de cualquier bloque:

Public void Main() { ... }

Establezca una longitud de lnea mxima para el cdigo. Utilice espacios antes y despus de los operadores siempre que eso no altere la sangra aplicada al cdigo:
miVariable = 3; en vez de miVariable=3;

Use espacios en blanco para organizar a su antojo secciones de cdigo. De tal manera que se comprenda la segmentacin del cdigo. En casos donde lo amerite utilice regiones.

Cuando tenga que dividir una lnea en varias, aclare que el cdigo sigue en la lnea de ms abajo mediante un operador de concatenacin colocado al final de cada lnea, y no al principio.

Siempre que sea posible, no coloque ms de una instruccin por lnea, a excepcin de los bucles.

Al escribir en HTML, establezca un formato estndar para las etiquetas y los atributos; como por ejemplo, las etiquetas siempre en mayscula y los atributos en minscula

Cuando escriba instrucciones SQL utilice maysculas para las palabras clave: SELECT, UPDATE, WHERE, FROM, etc.

Coloque las clusulas SQL principales en lneas separadas, de modo que las instrucciones sean ms fciles de leer y editar:
SELECT Nombre, Apellido FROM Clientes WHERE Fecha= Now.Today;

Cuando aplique mas de un atributo a una estructura colquelos individualmente en una lnea y no todos juntos y separados por comas.

Siempre que sea posible inicialice las variables en el momento de la declaracin (no es necesario en VB).

Siempre utilice los tipos nativos de cada lenguaje y no los del CTS. Evite hacer unboxing y boxing secuencialmente, es decir en la misma rutina. No compare strings con o con string.empty, use la propiedad length del string:
If(String.length == 0)

Evite llamadas a mtodos dentro de sentencias condicionales. Evite utilizar recursividad, use mejor ciclos for anidados. Use el operador condicional ternario solo en casos triviales, cuando sean casos complejos evtelo. Evite comparar variables booleanas contra false o true, en vez de eso utilice el operador de negacin:
If(puedeEliminarse == true) if(puedeEliminarse=false)

Mejor use
If(puedeEliminarse) f(!puedeEliminarse)

ADICIONALES

Evite referencias mutuas entre dos ensamblados. Nunca omita los modificadores de acceso, declrelo siempre explcitamente. Para el control de Cdigo Fuente se debe utilizar Visual Source Safe.

Para desplegar mensajes de error se debe usar los errores personalizados utilizando ASP web Pages. Tambin podemos utilizar MessageBox con JavaScript. Las excepciones se deben capturarsiempre en el nivel mas alto del sistema, es decir en la capa de mas abstraccin, por lo general es la capa de interfaz de usuario. Es una directiva general evitar en todo caso crear excepciones personalizadas, pero en el caso de que sea necesario siga estas premisas:

Se

deben

manejaren

clases

aparte

se

debe

heredar

de

la

clase

ApplicationException. Se debe sobrescribir el mtodo ToString(). Implemente el patrn de diseo de las excepciones, sobrescribiendo estos 3 mtodos :
public MiExcepcion() public MiExcepcion(string message) public MiExcepcion(string message, Exception innerException)

Nunca declare una sentencia catch vaca. Evite anidar bloques try/catch. Ordene la captura de excepciones (catch) siempre en orden descendente desde la ms particular hasta la ms genrica. Evite relanzar una excepcin, permita mejor que vaya ascendiendo y que sea capturada en la capa superior. Si relanza una excepcin omita la referencia:
Try { .... }

catch (Exception e) { throw } (no use throw e)

Use los bloque finally solo para realizar funciones de limpieza y liberacin de recursos.

Siempre que sea posible prefiera la validacin al manejo de excepciones:

Try { conexin.Close() } catch (Exception a) { ... Manejo de excepcin }

cmbielo por:
if(conexin.State() != Conecction.State.Closed ) { con.Close();