Código limpio

2,520 views

Published on

Buenas prácticas de programación
Código limpio

Published in: Education
2 Comments
0 Likes
Statistics
Notes
  • Muchas gracias por tu aportación Pol, un saludo
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Diapositiva 2. Ocultar errores es la peor practica que se puede llegar a hacer, sobretodo con la @ en php. Justamente lo correcto es evitar esos errores. La gente que mantendrá el código posteriormente lo agradecerá.

    Por otro lado me cruje ver variables y funciones en castellano mezcladas y ademas mezclados con tipos de datos en inglés (JugadoresList) , lo más adecuado es que el código esté en ingles, sino, ya que si todos escribieramos en nuestro idioma, el dia que tuvieramos que mantener el código de un hindú o de un chino nos acordariamos de los ancestros del que lo ha escrito.

    El resto depende mucho del lenguaje y la convención de este, no se escribe igual en python que en c#, aun así veo mucho mas importante tener coherencia en tu propio código, o con el del resto del proyecto si no lo has empezado tú.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
2,520
On SlideShare
0
From Embeds
0
Number of Embeds
812
Actions
Shares
0
Downloads
25
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

Código limpio

  1. 1. Calidad de código
  2. 2. 2/24Evita los NOTICES por desbordamientos de arrayasociativo error_reporting(0); error_reporting(E_ALL ^ E_NOTICE); Una forma mucho más elegante de hacerlo:
  3. 3. 3/24Evita los comentarios papagayo
  4. 4. 4/24Comenta cada fichero, arriba, en la cabecera
  5. 5. 5/24Comenta cada función, encima, en su cabecera Incluye los comentarios de lo que hace la función arriba, evita comentar en medio del código
  6. 6. 6/24Elimina el “código chatarra” de tu código deexplotación Trozos de código comentado Funciones que no se usan Variables que no se usan Ficheros que no se usan ...
  7. 7. 7/24Algunas normas de notación Variables: camel (inicial minúscula) Clases: camel (inicial mayúscula) Funciones, métodos: camel (inicial minúscula) Ficheros: camel (inicial minúscula) Tags y atributos HTML: minúsculas
  8. 8. 8/24Separa lógica de negocio y presentaciónERROR: Se mezcla lógica ypresentación
  9. 9. 9/24Identación: establece siempre mismo espacio detabulación
  10. 10. 10/24Sé consistente con los tipos Dentro del fichero cronometro.js: ● ¿qué utilidad tiene la variable intentos? ● ¿Qué tipo de dato le va a asignar el parser de JS? ● ¿Qué tipo de dato habría sido más adecuado?  ¿De qué tipo son los datos que almacena?  Hubiera sido más adecuado entrecomillar  Mejor haber usado array asociativo para cachear BBDD en memoria
  11. 11. 11/24Nombres de variables alusivos a su cometido En la práctica del juego del cronómetro, qué significado crees que tienen las siguientes variables: var RALI; $_POST[“peticion”] var interruptor, interruptor2, interruptor3; var RASI;
  12. 12. 12/24Cuida el lenguaje, nunca sabes a dónde puede llegartu código
  13. 13. 13/24Identación de bloques de código Errores de identación!!! ● Antes de una llave abrir, un espacio ● Después de una llave abrir, nueva línea ● Las instrucciones dentro de un bloque, una tabulación a la derecha ● La llave cerrar en una nueva línea, justo a la altura de la instrucción que abrió el bloque ● Detrás de la llave, instrucciones con idéntica tabulación que la llave cerrar
  14. 14. 14/24Identación de funcionesfunction funcion1() {    instruccion1;    instruccion2;    instruccion3;} Coloca exactamente un espacio Idéntica tabulación para las instrucciones consecutivas
  15. 15. 15/24Identación de bloques if    instruccion1;    if ((x < 4) || (i <= 3)) {        instruccion2;        instruccion3; ● Operadores relacionales, aislados    } con un espacio a cada lado    else { ● Cada condición con su propio paréntesis        instruccion4; ● instrucciones dentro del if, 1    } tabulación derecha    instruccion5; ● instrucciones dentro del else, 1 tabulación derecha ● Llave abrir, 1 espacio antes ● Llave cerrar justo debajo del if/else ● Al cerrar la llave, eliminamos 1 tabulador izquierda
  16. 16. 16/24Alert: Minimiza su uso Los mensajes de Alert resultan molestos en la navegación
  17. 17. 17/24Aisla la declaración de estilos a .CSS Ejemplo de correcto aislamiento:
  18. 18. 18/24Aisla la declaración de estilos a .CSS Ejemplo de mal aislamiento:
  19. 19. 19/24Nombres de funciones deben contener un verbo Las funciones son una acción, luego deben contener un verbo: actualizarResltado, calcularCoste, envierCorreo, comprobarLogin,... Una función que se llama cronómetro, ¿qué hace? ● Difícil de intuir sin leer el código
  20. 20. 20/24Nombres de clases deben ser un sustantivo Nombres como Jugador, JugadoresList, Partida, Torneo,... son nombres válidos de clases NO tiene sentido una clase que se llame SortearPartido, parece más lógico que se trate de un método de una clase
  21. 21. 21/24Nombres de fichero alusivos a su contenido Imagina los siguientes nombres de fichero: ● javascript.js ● js.js ● utilidadesFechas.js ● funcionesCifrado.js Los dos primeros es algo así como decir “Sube parriba”
  22. 22. 22/24Cada función entre líneas de separación// ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­function f1() {    ...}// ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­function f2() {    ...}// ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
  23. 23. 23/24Nombres de fichero alusivos a su contenido Imagina los siguientes nombres de fichero: ● javascript.js ● js.js ● utilidadesFechas.js ● funcionesCifrado.js Los dos primeros es algo así como decir “Sube parriba”
  24. 24. 24/24Declaración de variables: nunca en medio Las variables podemos declararlas al comienzo del fichero, como variables globales También podemos declararlas al comienzo de una función Evitar su declaración en medio del códigofunction f1() { OK    var x;    var y;    instruccion1;    instruccion2; !!!    ...    var j;    instruccion12;}

×