La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Convenciones de nomenclatura y diseño

Presentaciones similares


Presentación del tema: "Convenciones de nomenclatura y diseño"— Transcripción de la presentación:

1 Convenciones de nomenclatura y diseño
Variables locales: Notación camello. e.g.: anyName Métodos y clases: Notación pascal. e.g.: GetName() Variables globales: Prefijo _ y notación camello. e.g.: _name. Definir los namespace con la estructura <NombreDeCompañía>.<NombreDeProducto>.<MóduloSuperior>. <MóduloInferior>. e.g.:TorresGuarin.Relampago.Web.BusinessObjects Escribir una sola instrucción por línea. Escribir solo una declaración por línea. Configurar la indentación de 4 espacios. Agregar una línea en blanco entre definiciones de métodos y definiciones de propiedades. Utilizar paréntesis para encerrar las expresiones e.g.: if ((val1 > val2) && (val1 > val3))

2 Convenciones de nomenclatura y diseño
Nunca utilizar notación húngara. No utilizar abreviaturas al nombrar las variables. Sólo utilizar variables de un solo carácter en los ciclos (i, n, s, etc.). Las variables booleanas se deben nombrar anteponiendo el prefijo is, obviamente respetando las diferentes notaciones. e.g. bool isCorrect = true, bool isFileFound = true. Nombrar clases y métodos con el formato <acción/verbo><Sustantivo> las rutinas que ejecuten alguna operación en un determinado objeto. e.g.: CalculateInvoiceTotal(). Los nombres de los métodos deben expresar el “qué” y no el “cómo”. Correcto: GetNextStudent() Incorrecto: GetNextArrayElement()

3 Convenciones de los comentarios
Situar el comentario en una línea separada y no al final de una línea de código. Comenzar el comentario con una letra en mayúscula. Finalizar el comentario con un punto final. Insertar un espacio entre el delimitador de comentario (//) y el texto del comentario. e.g.: // The following. Utilizar para comentar solo los delimitadores //. Los comentarios deben estar al mismo nivel de sangría del código. Al modificar el código, se deben actualizar los comentarios circundantes. Se debe comentar al mismo tiempo que se desarrolla.

4 Directrices del lenguaje
Utilizar el operador + para concatenar strings cortos. Para agregar cadenas en bucles y especialmente cuando los textos son largos se debe utilizar StringBuilder. Si se desea utilizar el tipo var (implicit typing) para las variables locales solo se debe usar si el tipo de la variable del lado derecho de la asignación es obvio o cuándo el tipo de la variable no es importante. Correcto: var var1 = "This is clearly a string."; Incorrecto : var var2 = ExampleClass.ResultSoFar(); Utilizar tipos con signo en lugar de los tipos sin signo. Utilizar && en lugar de & y || en lugar de | en los condicionales. Utilizar el prefijo I para interfaces.

5 Prefijos al nombrar controles de la interfaz gráfica:

6 Directrices del lenguaje
Las llaves deben estar al mismo nivel que el código fuera de las llaves. Las llaves de if y for deben estar en una línea separada de la declaración del condicíonal o del ciclo. Usar espacio para separar un grupo lógico de código. Debe haber una y solo una línea en blanco entre cada método dentro de las Clases. Espacio simple antes y después de los paréntesis y los operadores. Se debe minimizar el uso de abreviaturas al definir variables o métodos. Al escribir instrucciones SQL se utilizan las mayúsculas para palabras clave de SQL, y mayúsculas y minúsculas para tablas, columnas y vistas

7 Buenas prácticas de programación
No escribir métodos superiores a 40 líneas. En nombre de los métodos debe decir lo que hace. No usar nombres engañosos. Un método debe tener solo una tarea, aún si la tarea es muy pequeña. Usar los tipos específicos de C# o VB y no los tipos definidos de System (int si, Int16 no). No incrustar números en el código. Usar constantes. Los mensajes de error deben ayudar a resolver el problema. Nunca: “Error en la aplicación”, sino: “Fallo al actualizar la base de datos”. No incluir mas de una clase en un solo archivo. No tener archivos de mas de 1000 líneas de código.

8 Buenas prácticas de programación
Usar #region para agrupar piezas de código juntas. El código debe verse con la estructura que se muestra a continuación.

9 Bases de datos No incorpore el tipo de datos en el nombre de las columnas (notación húngara), pues al necesitar cambiar el tipo de datos lo obligaría cambiar adicionalmente el nombre de la columna. Los nombres de las tablas deben ser en singular. Correcto: Employee. Incorrecto: Employees. El nombre de las columnas no debe contener el nombre de la tabla. Incorrecto: EmployeeLastName. No utilizar el prefijo sp para los stored procedures. No utilizar el prefijo fn para las funciones definidas por el usuario. No utilizar el prefijo xp para los procedimientos almacenados extendidos.


Descargar ppt "Convenciones de nomenclatura y diseño"

Presentaciones similares


Anuncios Google