Lineamientos Generales para todos los lenguajes
- Los métodos y variables privadas comienzan con minúscula y se escriben en formato «camelCase»
- Los métodos, variables y propeidades públicas comienzan con mayúscula y se escriben igual en formato «Camel Case»
- Las constantes se escriben usando todas las letras en mayúscula y separándo palabras con «guión bajo». Ej.: MI_CONSTANTE
- Haga declaración explícita de las variables locales
- Evite el uso de variables globales
- Las declaraciones de variables se agrupan al principio de clases y métodos. En ocasiones es adecuado declarar una variable pública justo antes de la declaración de un método que use esa variable de manera exclusiva o prioritaria.
- Está bien declarar variables que se usan exclusivamente en bucles iterativos (for-loops) en la declaración de dichos bucles.
- Inicialice las variables que declara, y escriba su lógica de manera que pueda procesar valores «undefined/falsy/null»
- Evite el uso de raya baja o guiones en los nombres de métodos o variables. En casos excepcionales se puede usar raya baja para describir alguna situacion consistente a lo largo del proyecto. Por ejemplo es mejor escribir
var blueColor
quevar blue_Color
. Pero podría ser adecuado escribirfunction testControllerInit_SuccessCase()
- Como convención de nombramiento, use verbos para los métodos y sustativos para las propiedades.
- Evite el uso de valores literales «hard0-coded» en diversos lugares. Hágalos reusables en constantes.
- Los operadores lucen mejor con espacios al rededor. Por ejemplo es mejor escribir
var x = 10 + 10;
quevar x=10+10;
- La indentación es primordial. Muchos editores de código traen herramientas para indentar adecuadamente el código.
Good tools for code auto-format are Netbeans, Atom and Visual Studio Code. - Utilice las herramientas de análisis estático de códigopara encontrar variables no utilizadas, métodos demasiado largos y errores de sintaxis. NetBeans provee herramientas muy útiles para lenguajes como JS, CSS, PHP, TypeScript, C++ y HTML.
- Mantenga las líneas de código de una longitud menor a 80 caracteres.
- Mantenga los métodos de una longitud menor a 30 lines
- Mantenga las anidaciones a menos de 3 niveles
- No deje código comentado. Escriba comentarios para encontrar código legado en su lugar.
- Evite comentarios innecesarios y reiterativos como /*This function creates a user*/ para una función llamada «CreateUser(args)»
- Aproveche las facilidades de los ambientes de desarrollo para generar documentación a partir de comentarios estructurados. Especialmente para los Web API’s y las API’s en general.
JavaScript
- Nunca declare objetos de tipo Number, String or Boolean
- No use «
new Object()
«. Usevar x = {}
en su lugar. - Recuerde que JS tiene un mecanismo automático de conversión de tipos
- Use === en vez de == siempre que se pueda.
- En ocasiones es apropiado usar == cuando el tipo de los objetos no se ocnoce de manera predecible/estable. Sin embargo la situación de manejar objetos de tipo desconocido o impredecible debe ser evitada también.
- Ponga atención a los parámetros que adoptan una «definición» undefined cuando no se proveen en una llamada a una función y actúe consecuentemente.
- Termine los bloques «switch» con «defaults«
- Nunca use eval()
- Use nombres de variable significativos como
cuenta
orvalorPrevio
en lugar dec
orvp
- Es apropiado utilizar funciones anónimas cuando estas serán llamadas solamente desde un mismo lugar. En caso contrario es necesario extraer las funciones con un nombre apropiado en el entorno (scope) correcto.
- No deje sentencias de tipo «debugging» tales como console.log en el código del ambiente productivo.
- En JavaScript, iniciar una declaración de bloque con una llave «{» en la misma línea de la declaración es correcto:
var constants = {
COLOR_RED: "#FF0000",
COLOR_GREEN: "#00FF00",
COLOR_BLUE: "#0000FF"
}; - Referencias:
HTML
- Utilice etiquetas en minúscula de manera consistente. Use
<div>
en lugar de<DIV>
- Asegúrese de cerrar todas las etiquetas HTML de manera apropiada. Por ejemplo,
<div>
debe cerrar con una etiqueta de cierre</div>
mientras que<hr>
luce mejor si se cierra de manera individual<hr />
- Utilice minúsculas para los nombres de atributo. Also, use camelCase format for ID’s of DOM elements. I.e.:
<div id="myDiv">...</div>
- Utilice guiones para separar palabras en los nombres de las clases CSS:
<div id="myDiv" class="jumbotron-alternative">...</div>
- Use comillas dobles para declarar los valores de atributos HTML: I.e.:
<div id="myDiv" class="jumbotron-alternative">...</div>
- Use las etiquetas <table> apropiadamente para elementos tabulares no para generar estilos o layout.
- No agregue espacios entre los nombres de atributos, símbolo de igualdad y los valores de atributos.
This is good:<link rel="stylesheet" href="styles.css">
This is bad:<link rel = "stylesheet" href = "styles.css">
- Utilice indentación apropiadamente, especialmente con elementos jerárquicos como listas, tablas, entradas de selección.
- Evite usar espacios en blanco, líneas en blanco o indentación innecesaria.
- Use comentarios de manera apropiada:
Good for short comments:<!-- This is a comment -->
Good for longer comments:
<!--
This is a long comment example. This is a long comment example.
This is a long comment example. This is a long comment example.
-->
- Las definiciones de estilo van en un archivo separado, no en el código HTML. Nunca use estilos «en-línea»
- Coloque las referencias a archivos JavaScript al final del código HTML
- Valide su código HTML por medio de análisis estático. Netbeans tiene muy buenas herramientas de análisis estático para HTML.
- Utilice nombres con significado para variables y reglas de estilo/clases.
- Referencias:
CSS / SCSS
- Los estilos van en archivos separados del código HTML.
- Es apropiado escribir reglas cortas CSS en una sola linea.
- Las reglas más largas (que involucran multiples configuraciones) deben hacerse en modo multi-línea.
- Nótese que CSS suporta comentarios
- Referencias:
AngularJS Specific
- Organice las carpetas y archivos en una estructura basada en componentes.
- Remueva las dependencias no usadas en los controladores. Netbeans tiene buenas herramientas de análisis de código para detectar código no utilizado.
- Es apropiado usar funciones anónimas en controladores si estas serán llamadas desde un solo lugar. De lo contrario, es mejor agregar una función no-anónima y hacer las llamadas respectivas por medio de dicha función.
- Se recomienda usar notación de arreglo al instanciar controladores.
- Mantenga la lógica de presentación fuera de los controladores. Los controladores manipulan e modelo de datos y las vistas son quienes reaccionan a los cambios realizados en esos modelos. Los controladores no deben realizar llamadas de tipo document.getElementByID para encontrar elementos del DOM en una vista.
- Referencias:
C# and .Net
- Haga uso extensivo y prudente del registro de eventos de manera que se pueda habilitar solución expedita de problemas en ambientes productivos.
- WIP
SQL Server
- Tenga cuidado del acople y la cohesión al desarrollar Procedimientos Almacenados.
- Use Procedimientos Almacenados y/o vistas cuando esto mejore de manera significativa los procesos de acceso a datos. Especialmente consultas de múltiples tablas.
- WIP
TypeScript
- Una buena referencia a TypeScript: https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines
16,892 total views, 3 views today
Comentarios