Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

mig21 (7781)

mig21
  reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw

Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames ;)

No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...

Esta es toda mi información de usuario :)

Down Kill Up Publicidad

Bitácora de mig21 (7781)

Miércoles, 10 de Diciembre 2003

Consejos de programación

09:05h.
Tecnología
Ultimamente me ha tocado revisar/corregir código ajeno y me he dado cuenta de la cantidad de reglas simples y útiles que no se siguen. Por eso voy a hacer una enumeración de las que más me han servido por si le son útiles a alguien. La mayoría son lógicas, pero está bien leerlas alguna vez:
  • Código sencillo: Para mi la más importante y la más difícil. Si tu código se complica demasiado puede ser que no lo estés haciendo bien. Párate a pensar y quizás se te ocurra una solución más elegante. En inglés conocido como KISS (Keep It Simple, Stupid)
  • Código no repetido: Es muy importantante no repetir código. Ayuda a tener las cosas que hacen lo mismo juntas y poderlas encontrar y cambiar fácilmente. Este principio es conocido también bajo su acrónimo inglés DRY (Don't Repeat Yourself). Más información en una entrevista a Andy Hunt y Dave Thomas y en una entrada en la bitácora de Bruce Eckel
  • Código comprensible: Trata de escribir cómo si te fuese a leer alguien. Tanto en el nombrado de las variables, funciones, métodos, clases como en la implementación de estos. Usa nombres expresivos, que a la hora de usarlos reflejen su significado. A veces ejemplos de como no nombrar son ilustrativos :)
  • Código compacto: El agrupamiento de código en forma de funciones o objetos se hizo para algo. Úsalo. Casi nadie es capaz de revisar una función/método de 2000 líneas y seguro que se puede descomponer en subpartes. En el "Linux kernel coding style" hay una frase radical pero para mi muy cierta:

    if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program
  • Código mantenible: Piensa que el código no es para siempre. Habrá que retocarlo o modificarlo. Pensar en ello mientras estás codificando puede ayudar mucho a posteriori. Para ilustrarlo podemos hacer un repaso a cómo hacer código inmantenible, divertido pero revelador.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.