Barrapunto

Este es sin duda un libro muy recomendable: http://www.amazon.co.uk/Pragmatic-Programmer-Andre w-Hunt/dp/020161622X [amazon.co.uk] Hay otros, pero este es un clasico que vale mucho la pena leer

A mi sin lugar a dudas el mejor libro con diferencia me parece "Code Complete":

http://cc2e.com/ [cc2e.com]

Cubre todas las areas: optimizacion de codigo, reglas de estilo, estrategias de refactorizacion, observaciones para escibir codigo seguro...

Y todo esto para c++, Java y si no recuerdo mal en las ultimas ediciones C#

Directamente yo hubiera pedido consejo a los barrapunteros sobre sus hábitos de programación... pero han empezado ¡pidiendo documentación! ¡Eso ya es un buen hábito! :-P
Algo que suele influir en tener buenos hábitos de programación es el lenguaje con el que te iniciaste y la metodología que te inculcaron. No coges los mismos hábitos aprendiendo a programar con BASIC que con Pascal.
Me ha venido a la mente esta guía de qué no hacer [uniovi.es], que si bien habla de una práctica de programación en concreto, tiene puntos aplicables a la programación en general.

A mí me gustó leer las guías de estilo de código de Linux [gnome.org]. Son un bastante bordes, pero supongo que hay que tomárselas con buen humor.

El caso es que son amenas y, aunque no son una biblia de cómo escribir, sí te hacen reflexionar en algunos puntos sobre temas como la extensión de las funciones o el exceso de anidamiento.

Yo las encontré por casualidad en un archivo dentro de la instalación, no sé si se instala con el código de Linux ni cómo se llamaba el archivo, pero sí me parece recordar que era más extenso que las versiones que he encontrado en la web.

En fin, mis consejos son:
* Programa pensando en el cambio: sabes que lo que hacen las funciones va a ir cambiando con el tiempo, así que intenta tener en mente que los cambios impacten la menor cantidad de código posible.
* Es un coñazo, pero documenta con los comentarios todo lo importante que no sea obvio, no confíes en tu memoria (sobretodo si lo tiene que leer otro). Dentro de las funciones deja los comentarios al mínimo (para cosas raras) y concéntrate mejor en comentar cada función (es más importante saber qué hace una función que cómo lo hace).
* Intenta seguir éste consejo de la guía que te he puesto antes: que cada función haga una cosa y la haga bien. Si una función tiene que hacer tres cosas, divídela en tres y considera si es mejor hacer luego otra función que llame a las tres, o llamar a las tres por separado desde el código principal. Para agrupar funcionalidad guíate por la lógica, de forma que la estructura del código se parezca al modelo mental.

..."La práctica de la programación" [agapea.com], de Kernigham y Pike.

No es muy caro pero sí muy recomendable. No te va a decir nada que no sepas :D

Los ejemplos están en pseudocódigo, pascal, C, C++, Java, Perl, Python, ... No se centra en un lenguaje concreto.

Esta me parece una muy buena referencia [mindprod.com] para tomártelo con humor (en inglés).

Sé que el uso excesivo de capas ha sido criticado aquí últimamente, pero intenta guardar cierto mínimo.

No hay nada peor que mantener un proyecto donde encuentras junto código de presentación y sentencias SQL.

Modulariza. Que la mano izquierda no sepa lo que hace la derecha. Así cuando tengas que cambiar algo de una, la otra no se enterará.

Y ya lo han dicho, pero piensa en el cambio. No tienes que implementar todo exhaustivamente, pero déjalo lo suficientemente abierto para que las extensiones no sean dolorosas.

Primero es importante diseñar correctamente tu programa, para ello UML [wikipedia.org] viene muy bien.

Si tu programa es pequeño, da igual pero si empieza a crecer, un buen diseño te evitará:
a) Perder el tiempo solucionando problemas que se verían en el diseño (no tirarás código a la basura)
b) No entender que hace alguna parte de tu programa por una mala documentación (el diseño documenta)

No obstante el diseño != implementación, hay cosas que en la implementación se hacen al margen del diseño, así que deberías documentarlas.

Libros interesantes dependen de lo que vayas a hacer...
Se me ocurre alguno sobre patrones de diseño, sobre UML (o OMT si no tienes a mano de UML).
Otros menos interesantes, podrían ser libros sobre el lenguaje que usas en plan "como está implementado el lenguaje", de esta forma, verías como implementa el lengaje cosas como la herencia, parámetros... que pueden ser útiles a la hora de mejorar la eficiencia del programa.
Alguno sobre optimización de código podría ser interesante, por el tema de caches/fallos de página y esas cosas.

Si programas en un lenguaje orientado a objetos deberías aprender sobre patrones de diseño. También recomiendo un libro en inglés, Effective Java, que acaba de salir en su segunda edición y que está creado por una de las personas que curró desarrollando Java.

Una idea interesante es aprender lenguajes de paradigmas diferentes a los que estás acostumbrado. Aunque pueda parecer que no tiene sentido, adquieres nuevas ideas, y enfocas las cosas de distinta manera.

Por ejemplo, a mí aprender a usar lenguajes funcionales me ayudó con C/C++, porque descubrí el valor de las funciones puras (funciones sin estado), y eso me permite modularizar mejor el código.

El termino es inglés, en castellano sería algo como: "-bilidades".

Coge una lista de características de calidad [wikipedia.org] y trata de incluir el máximo en tu programa.

Por ejemplo: tu programa funciona. ¿Pero que pasará si un día falla algo? ¿Has pensado en la recuperabilidad? La recuperabilidad es la propiedad de un sistema para recuperarse de un fallo. Si se ha desconectado del servidor por un fallo en la red que se reconecte automáticamente cuando vuelva a haber conectividad, por poner un ejemplo.

Coge otra característica, por ejemplo escalabilidad. ¿Tienes algoritmos con orden n^2? ¿Metiendo más máquinas puedes atender fácilmente a más usuarios? ¿Seguirá funcionando el sistema mañana si tiene exito?

Practica pensando en que características de la lista son más importantes y aplica el sentido común para llevarlas a la práctica. Completa el sentido común con recetas de otros: patrones, algoritmos, tecnologías, ...

Discute con tus compañeros de forma sana, más perspectivas enfocando el problema hará que lo analices mejor.

Si sigues estos consejos, nunca estarás a gusto con ningún código que desarrolles. Siempre encontraras un pero donde mejorar. Tendrás que sacrificar en rendimiento para mejorar la legibilidad o reusabilidad del código, sacrificarás la degradabilidad en pro de la simplicidad, ... Pero siempres tendrás un reto: agudizar el ingenio para sacrificar menos cosas. Y eso siempre con la fecha de entrega pisandote los talones.

si te refieres al diseño, el patrón experto es para ti:
http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseN otes/maps/class4/InformationExpert.html [wpi.edu]
(me ha costado un huevo encontrarlo)
y en general, el resto de patrones de diseño y otras reflexiones sobre ingeniería de software.

si te refieres a la implementación, el principio KISS
http://es.wikipedia.org/wiki/Principio_KISS [wikipedia.org]
linux kernel coding style
http://pantransit.reptiles.org/prog/CodingStyle.ht ml [reptiles.org]
mozilla coding style guide
http://www.mozilla.org/hacking/mozilla-style-guide .html [mozilla.org]
y más específicamente, la guía que se utilice en el proyecto en el que participes serán textos a tener en mente.

una cualidad a mi modo de entender importantísima es conseguir una alta e indolora verificabilidad del código. dentro de las tácticas que te parezcan eficaces, utiliza la más eficiente. definir una constante llamada "DEBUG_MODE" para que las funciones la tengan en cuenta y escriban cosas al log si está a true me es útil.

notarás que lo estás haciendo bien si de aquí a 6 meses el código que escribiste hoy te da ASCO.

Puedes ver bastantes casos reales en The Daily WTF [thedailywtf.com].

1. Piensa siempre en por qué haces lo que haces.

¿Puedo ponerle un nombre más claro a este método? ¿Qué hace esta parrafada de código que he copiado de internet? ¿Hay una forma mejor de hacer esto? ¿Qué dice la documentación oficial de xxx?

2. No te repitas

Si haces mucho ctrl+c al programar, malo (el ctrl+x está bien).

Para todo lo demás, Mastercard^H^H^H^H^H^H^H^H^H^Hintenta leer buenos ejemplos. Si programas Java, p.ej. léete la excelente documentación de Sun. Si haces HTML, intenta leerte las cosas del W3C, etc. etc.

Los programadores de Perl tenemos, desde el 2005, el PBP (Perl Best Practices). Imprescindible.

La primera regla es:

        "Siempre programa como si la persona que acabe manteniendo tu código sea un violento psicópata que sabe dónde vives"

Creo que lo mejor es seguir una serie de normas genéricas, más o menos las siguientes:

* Tabula correctamente tu código
* Intenta que las líneas no sean demasiado largas
* Intenta separar bien el código por su funcionalidad: pon código que se repita mucho en funciones/métodos separados
* "Parametriza" todo lo que puedas: no escribas dos métodos parecidos que hagan cosas parecidas, intenta hacer uno solo que se comporte adecuadamente según la situación
* Piensa antes de programar. Esto resume un poco los anteriores puntos, pero es vital pensar antes de lanzarse a teclear. Puede ahorrarnos mucho trabajo y disgustos.
* Comenta lo que no sea obvio
* Intenta de vez en cuando programar sin usar un IDE que te autoformatee el código (al estilo VisualStudio) y comprueba después que tu código sea legible y funcione.
* Léete la guia de estilo del lenguaje que estes utilizando. Por ejemplo, en java: http://java.sun.com/docs/codeconv/html/CodeConvTOC .doc.html [sun.com] o en python: http://www.python.org/doc/essays/styleguide.html [python.org]
*El consejo de explorer sobre el violento psicópata me parece insuperable :)

Y creo que no se me olvida nada más. Espero que te ayude, pero desde luego escribir buen código es un largo camino que sólo se aprende con experiencia.

Un saludo.

PD: ¿Por qué en barrapunto hay tanta gente que odia Java? No será el mejor, pero tampoco creo que sea tan malo como lo pintan...

... y despues de leer todo lo anterior, te recomiendo http://www.literateprogramming.com/ [literateprogramming.com]

Suena a Perogrullo, y lo es, pero se olvida siempre.

Se han dado buenos consejos en los hilos y otros bastantes malos.

Pero saber programar, no es poner una sentencia detrás de otra, es hacerlo con una lógica bien pensada de antemano, utilizar los comentarios adecuados para entender el funcionamiento del código, organizar el código adecuadamente al uso que se le va a dar, usar identificadores que revelen el uso, evitar atajos que son muy bonitos pero que hacen el código ilegible (cada lenguaje tiene sus atajos particulares que los friquis del lenguaje utilizan abundantemente convirtiendo el código en un jeroglífico indescifrable), etc ...

En definitiva hay que tener un método de trabajo y aplicarlo a lo largo de todo el código, función, proyecto, o lo que sea. La coherencia del código con el método de trabajo es fundamental, es decir utilizar siempre los mismo hábitos de codificación (siempre que sean buenos hábitos) hará que los demás lo entiendan más fácilmente.

Por ejemplo, yo jamás ahorro una línea de código si con ello hago más legible el código, aunque me digan que es redundante. Si es redundante ya se encargará el compilador/interprete de optimizar el código, que para eso están (sino seguiríamos programando en ceros y unos o a lo sumo en ensamblador). Así, para las condiciones de las sentencias siempre utilizo una variable booleana, que asigno previamente al predicado de la condición (aunque en los lenguajes que hay que declarar las variables al principio es muy pesado, hoy, los lenguajes más comunes permiten declarar las variables según las necesitas).

Esto a mi me vale porque hace más legible el código a otro programador y a mi mismo, y facilita el mantenimiento. Y a otros les valen otras cosas. Pero sobre todo lo importante es mantener la coherencia del método a lo largo del código.

En definitiva, lo importante no es el lenguaje, ni el código, sino, saber programar. Y saber programar no es solamente escribir código, sino pensar, pensar en el algoritmo adecuado, pensar en el lenguaje o tecnología adecuada para el problema, pensar en el método de trabajo adecuado, pensar en el mantenimiento del código, pensar... , pensar..., y pensar...

Eso puede estar bien para martillearte y que se te queden, pero creo que está bien aprender antes cuáles son las normas y el por qué.

En cuanto a Spring, es muy cierto que te incita a hacer las cosas bien, lo malo es que cuando no puedes (o no sabes) hacer las cosas bien, tienes que montarte rodeos increíbles. A veces me he visto obligado a hacer trozos de código que me han avergonzado profundamente (eso sí, si tienes que hacer un wtf, al menos explícalo bien en los comentarios).

Nunca te dejes llevar, acepta solo las soluciones mas finas;

Una verdad que se aprende en el mundo real, y dicha por todos los gurús, es "Optimizar demasiado pronto es malo". Diséñalo, impleméntalo y luego optimiza.

Puedes pasarte la vida rehaciendo un programa para llegar a la perfección. Hacer un programa no es una obra de arte, es una tarea que tiene que terminarse alguna vez. Más concretamente hay un plazo a partir del cual la tarea deja de ser útil.

Eso vale para la programación para un cliente, para software libre, o para tu casa. Una cosa es practicar e investigar técnicas, y otra hacer una aplicación.

Si quieres hacer un programa de una agenda sólo para ti, llevas 5 años con él, y aún no es funcional porque quieres hacerlo con las mejores técnicas y el sumum de la perfección, no te engañes, estás practicando e investigando, no haciendo un programa de agenda. La mejor prueba de ello es que no lo tienes, ni tienes previsto tenerlo nunca.

Conste que no veo nada malo en investigar y probar cosas, pero siempre que uno tenga claro que eso es lo que está haciendo.

Me parece malo que un programador con talento caiga en esta confusión en su casa sin ser consciente. Me parece triste cuando veo esa actitud en algunos círculos de software libre. En el mundo de la empresa no me parece ni me deja de parece nada. El que lo hace dura poco en el negocio.