Buenas Practicas de Programción en c# Segunda Parte

Como lo prometido es deuda, aqui estoy con la segunda parte del post de Buenas Practicas de Programacion en c#.

Comencemos con SQL

En base de datos, es recomendable:

1. Stored Procedures deben nombrarse con prefijo “spr_”. NO usar nunca “sp_”, La razón es que: SQL Server reconoce el prefijo “sp_” como “System Stored Procedure”, es decir, un procedimiento almacenado de Sistema y lo buscaría en la Base de Datos “Master”.

2. Tablas “tbl_” ….

3. Vistas “vw_” …

Volviendo al código c#

1. Usa #region para agrupar código. En mi caso suelo usar de la siguiente manera

#región –[Variables Privadas]– #End Region

#región –[Propiedades Privadas]– #End Region

#región –[Metodos Privados]– #End Region

#región –[Eventos]– #End Region

#región –[Propiedades Publicas]– #End Region

#región –[Metodos Publicos]– #End Region

la idea es mantener las variables globales, las propiedades y los métodos, todos ellos privados en la parte superior del archivo y los elementos públicos en la parte inferior.

Metodos

1.  Un método debe tener entre 1 a 25 líneas de código. Si un método tiene más de 25 líneas de código, debes considerar refactorizarlo en métodos separados.

2. El nombre de los métodos debe decir lo que hace. Si el nombre del método es obvio, no hay necesidad de summary.

3. Un método debe tener solo “una tarea”. No combines más de una tarea en un solo método, aún si esas tareas son pequeñas.

4. Evita métodos y propiedades públicas, a menos que ellas realmente necesiten ser accedidas desde afuera de la clase. Usa “internal” si ellas solo son accedidas dentro del mismo ensamblado. Normalmente pocos usan esta buena práctica, es muy recomendable.

5. Evita pasar muchos parámetros a un método. Si tienes más de 5 parámetros, define una clase o una estructura. Esto reduce el consumo en memoria, evita la corrupción de datos, y disminuye la exigencia a los ciclos del procesador.

6. Si tienes un método que retorna una colección, devuelve una colección vacía en vez de null, si no existen datos que retornar. Esto permite hacer una verificación por un count en vez de por null y luego por count.

Constantes, strings y de mas

1. Usar constantes en el código, no es recomendado.  Se debe usar las constantes en el archivo de configuración o en la base de datos, de tal forma que si a futuro deben cambiarse, sea menor el impacto.

2. Si debes comprar cadenas de texto recuerda convertirlas a mayúsculas o minúsculas según corresponda, estoy permitirá una mejor comparación.

3. Usa string.Empty en vez de “”.

4. Usa enum en donde sea requerido. No uses números o cadenas para indicar valores fijos

enum TipoCorreo
{
Html,
TextoPlano
}

switch ( tipoCorreo )
{
case TipoCorreo.Html:
//hacer algo
break;
case TipoCorreo.TextoPlano:
// hacer algo

}

5. Los eventos no deben contener el código que ejecute la acción requerida. En vez de ello, se debe llamar a otro método desde dicho evento, ejemplo:

protected void btnObtenerDatos_Click(object sender, EventArgs e)
{
ObtenerDatos();
}

6. De la mano del punto anterior, no invoques desde código el evento Click, en vez de ello llama al método que es invocado desde el evento click.

7. No utilices código duro en rutas o letras de dispositivos. Obtén la ruta desde código.

8. Cuando inicia la aplicación, ejecuta una clase de “auto verificación” para asegurarte que todos los archivos requeridos y las dependencias están disponibles en las ubicaciones esperadas. Verifica las conexiones a la base de datos. En caso de algún problema, muestra un mensaje amigable al usuario.

9. Si el archivo de configuración requerido no se encuentra, la aplicación debe ser capaz de crear uno con valores predeterminados.

10. Cuando despliegues mensajes de error,  el mensaje también debe decirle lo que el usuario que debe hacer para resolver el problema. En vez de un mensaje como “Error al actualizar tus datos.”, sugiere lo que el usuario debe hacer: “Error al actualizar los datos, comprueba que tienes acceso a internet e inténtalo de nuevo.”.

11. Evita tener clases muy grandes. Si una sola clase tiene más de 1000 líneas de código, es un buen candidato para refactorizar. Divídelos lógicamente en dos o más clases.

Bueno esto es todo por hoy, muchas gracias por leer mi blog y espero te sirva de ayuda. En estos días prepararé la ultima entrega de buenas practicas, si deseas de que trate algún tema en especial por favor comunícamelo. Hasta la próxima.

Anuncios

2 Comentarios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s