buenas practicas de programacion

[carnagels880]

Hola muchachos, presento el siguiente problema, voy en el tema de los array, pero poseo problemas con las buenas practicas de programacion, me podrian colaborar mencionandome las mas primordiales, es que tuve un examen y el profesor me califico duro en ese aspecto

[gnzsoloyo]

Es una pregunta un poco abstracta... Cuando se habla de "buenas prácticas en programación" el tema suele ser enormemente extenso.

¿Qué fue exactamente lo que tu profesor te dijo, o qué te criticó?

[eferion]

Algunos ejemplos básicos:

1. Dividir el código en pequeños fragmentos, cada fragmento con un fin concreto (funciones)
2. Tabular el código con coherencia (todo el código que esté al mismo nivel debería tener la misma tabulación)
3. Utilizar una nomenclatura para nombrar funciones y variables (p.ej CamelCase, separar palabras por guiones '_', notación húngara, ... elijas lo que elijas tienes que mantenerlo en todo el código)
4. Usar nombres descriptivos para las funciones y las variables ('i' esta bien para un contador, 'numeroItems' queda claro para qué la vas a usar, pero 'var12' ¿para qué sirve? pues eso)

[superweb360]

http://r0d.developpez.com/articles/buenas-practicas/

[dehm]

Esta interesante el enlace, pero hay dos cosas que me han chocado:

- Lo de evitar tipos float en favor de double

y sobre todo:

Evitar usar archivos *.cpp e incluir todo en el *.h

¿Qué ventajas puede tener esto?

[eferion]

Iniciado por dehm

Lo de evitar tipos float en favor de double

double tiene mucha más precisión que float. Además la librería estándar suele trabajar con double... con lo que al usar double evitas continuos casts.

Iniciado por dehm

Evitar usar archivos *.cpp e incluir todo en el *.h

Si incluyes todo el código en el .h le das al compilador vía libre para que convierta en inline todas las funciones que crea convenientes... esto generará un código más rápido pero también más largo.

Yo personalmente no soy partidario de esta práctica ya que, salvo en contadas ocasiones, tal nivel de rapidez no suele compensar la pérdida de legibilidad que supone tener todo en la cabecera.

Otro problema de tener todo el código en la cabecera es que ante cualquier cambio, por pequeño que sea, se obliga a una recompilación en cascada de todos los archivos que dependan del archivo modificado... mientras que una edición en un cpp únicamente obliga a recompilar dicho archivo.

[dehm]

Ah, pues gracias por las explicaciones.

Sobre lo de evitar el uso de punteros para crear memoria en el heap...ahora que está uno lidiando con Qt, hasta se hace extraño hasta de leer (aunque entiendo la motivación del autor de las recomendaciones)

Saludos

[eferion]

Iniciado por dehm

Sobre lo de evitar el uso de punteros para crear memoria en el heap...ahora que está uno lidiando con Qt, hasta se hace extraño hasta de leer (aunque entiendo la motivación del autor de las recomendaciones)

A ver, para objetos normales, que no sean demasiado pesados, no hay ningún problema en tirar de la pila en vez de acceder al heap... se fragmenta menos la memoria, es más rápido y te despreocupas de las lagunas de memoria... pero hay que tener cuidado con objetos más grandes... o con la recursividad... si la pila se llena tu programa va a reventar con muy poco estilo :)

[vangodp]

¿Que diferencias hay en ficheros .h o .hpp?? :/

[eferion]

Iniciado por vangodp

¿Que diferencias hay en ficheros .h o .hpp?? :/

En el sentido estricto ninguna... de hecho puedes usar la extensión que te de la gana a la hora de programar (como si usas .vdp).

Lo que sucede es que la convención dice que la extensión .h es para programar en C y .hpp la utilizada para C++... básicamente para ayudar a estructurar el código.

[vangodp]

Iniciado por eferion

En el sentido estricto ninguna... de hecho puedes usar la extensión que te de la gana a la hora de programar (como si usas .vdp).

Lo que sucede es que la convención dice que la extensión .h es para programar en C y .hpp la utilizada para C++... básicamente para ayudar a estructurar el código.

ok! Siempre uso .h, lo digo por si el IDE lo tratara de forma distinta a un .hpp, no se si eso puede pasar.

Gracias

[lareto]

Iniciado por dehm

Evitar usar archivos *.cpp e incluir todo en el *.h ...

No, espera, no es ése el sentido de la frase. El artículo dice:

Nunca incluir un fichero .cpp (salvo para los templates, y aun así, aconsejo poner todo el código en el .h, cuando la clase no es demasiado grande).

Ese párrafo se refiere a que no debe "incluirse" un fichero .cpp; es decir, no hay que hacer algo como esto:

Código C:

#include "fichero.cpp" // ¡Alerta!
 

Y la aclaración entre paréntesis se refiere a que acepta el #include de un .cpp si el fichero define un template. Pero en ese caso (y sólo para los ficheros que definen templates), si la clase no fuera muy grande, aconseja poner el código en un .h

[dehm]

Iniciado por lareto

No, espera, no es ése el sentido de la frase. El artículo dice:


Ese párrafo se refiere a que no debe "incluirse" un fichero .cpp; es decir, no hay que hacer algo como esto:

Código C:

#include "fichero.cpp" // ¡Alerta!
 

Y la aclaración entre paréntesis se refiere a que acepta el #include de un .cpp si el fichero define un template. Pero en ese caso (y sólo para los ficheros que definen templates), si la clase no fuera muy grande, aconseja poner el código en un .h

¡Pues es verdad! Gracias por la aclaración