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)

Martes, 23 de Noviembre 2004

Estándares de codificación en C++

11:08h.
Tecnología
En artima ha publicado un extracto de un nuevo libro que van a publicar Sutter y Alexandrescu: C++ Coding Standards. Tiene muy buena pinta, porque da consejos concretos para no encontrarse con las típicas piedras que C++ pone en el camino del programador. En el extracto publicado dan tres consejos:
  • Compilar limpiamente y con el más alto nivel en los warnings. Bueno, yo creo que es un poco excesivo eliminar todos los warning, pero si es muy importante saber porqué nos salen las advertencias y si es peligroso o no dejarlas pasar
  • Saber cuando y como codificar para concurrencia. Muy a tener en cuenta, saber si lo que hacemos soporta o no concurrencia, saber elegir una estrategia adecuada y conocer las especificaciones de la las librerías y plataformas con respecto a eso. Esto me recuerda un artículo que leí hace poco y que no he comentado por aquí: "Trials and Tribulations of Debugging Concurrency"
  • Preferir composición a herencia. Evitar la herencia salvo para casos que está previsto: sobreescribir métodos, polimorfismo.
Ah, muchos de ellos parecen válidos para otros lenguajes...
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.