Mejores prácticas en Java

[WHK]

Hola, he estado leyendo sobre mejores prácticas en java y he encontrado mucha información muy variada pero nada en concreto.

Específicamente lo que busco es saber el tipo de estilo de programación a utilizar, por ejemplo:

http://en.wikipedia.org/wiki/Indent_style

Por ejemplo en base a ese texto puedo decir que siempre he usado el estilo del kernel de linux pero... habrá algo en alguna parte que diga porque una forma de identar es mejor que otra y cual debería ser el mejor estandard para trabajar en ello?

Otra pregunta es por ejemplo esta que hice hace un tiempo:
http://stackoverflow.com/questions/27732707/best-practices-when-programming-conditional

El tema es que muchos dicen que depende de uno mismo pero cuando trabajas ya no depende de uno mismo, o sea, supongo que debe haber un orden y algún tipo de orden debe ser mejor que otro.

Viendo códigos de ejemplo directamente desde Oracle:
http://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html

Vi que también utilizan un estilo casi igual al del kernel de linux, por lo que veo parece que es el estilo mas estandarizado.

En resumidas cuentas... habrá algún libro, tutorial o semi-standard que hable de todo esto? y que sea preferentemente para desarrolladores java y que sea hecho por alguien reconocido o que tenga el apoyo de alguien reconocido como para fijar un único estilo de ahora en adelante.

Gracias.

[Gh057]

Hola WHK, creo que es muy relativo... depende tanto del lenguaje, como del entorno de trabajo y porqué no, personalidad de cada uno...
Por ejemplo yo he optado como muchos, al programar en C el estilo de K&R, aunque luego bien aparecieron (y seguirán apareciendo) identaciones más o menos claras, o más cómodas o rápidas para codear (siempre y cuando no se arme uno ya una plantilla...), luego en Java obviamente al comienzo uno "sigue" con el mismo estilo, hasta que toma alguno como referencia... creo que (por lo menos es mi visión personal) un toma el estilo de los desarrolladores del mismo lenguaje, para ir con el tiempo adaptándolo.

Por lo cual si me sentí cómodo con el de K&R, me resultó luego más lógico tomar el de Sun... 

Con respecto a las referencias de renombre, no me viene a la mente ninguno en este momento... pero si puedo indicarte dos buenos enlaces, tanto al mismo sitio de Oracle y al de Google referido al tema:

-> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
->https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s1-introduction

Espero que te sean útiles, saludos!
 

[MinusFour]

No se si exista un libro en específico en cuanto a la apariencia del código. Claro que si hay mejores practicas para programar en Java, pero no se basan en la apariencia del código. Creo que es un tema a la discreción del programador y hay gente que prefiere una forma a la otra. Aparentemente yo uso el estilo KNF, aunque la verdad no sabia que habia una denominacion para la forma en la que escribo mi código. Curiosamente adapte ese estilo cuando aprendí Java, mas que porque mis profesores escribian así sus códigos (a excepcion de uno). Mis compañeros sin embargo usaban la notacion que dices que tu usas y honestamente siempre me provocaba "algo" (soy ligeramente obsesivo compulsivo).

Edit: Aqui hay una pagina que hablan de ciertas reglas de indentado para java:

http://www.javaranch.com/styleLong.jsp

[~ Yoya ~]

En java no existe un estándar para Indentación.

Lo mejor es utilizar estilo del código ya existente o quizás el mismo estilo pero con algunos cambios. Ya que siempre se suele trabajar en equipo, la idea es que todo el que lea tu código se sienta aunque sea un poco familiar. Cuando el proyecto empieza se suele seguir el estilo de la persona a la que se le considera con mas conocimiento. Pero sobre el estilo de indentación, lo importante es hacer el código lo mas legible posible. Yo prefiero ver un código de 7 lineas que exprese muy bien lo que hace en cada linea a un código de 25 linea que utilice la mejor indentación que se ha identificado.

Y evita ligar el estilo de la programación estructurada en la programación orientada a objetos.

Por mi parte yo suelo utilizar el estilo de Allman.

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.

PD: En los documentos de Oracle, se hace mas enfatice en exponer lo que se quiere explicar lo mas simple posible a utilizar buenas practicas. Por eso encontraras documentos con ejemplos de código sobre algún tópico que violan los principios de la programación orientada a objetos.



Un gran libro con muy buenas practicas y que me sorprendio es: Effective Java (2nd Edition).

Siempre le doy una revisada, la verdad es un buen libro para tenerlo de referencia.

Te dejo algunos de los tópicos:

8 General Programming . . . . . . . . . . . . . . . . . . . . . . . . .209
Item 45: Minimize the scope of local variables . . . . . . . . . . . . . . . 209
Item 46: Prefer for-each loops to traditional for loops . . . . . . . . . 212
Item 47: Know and use the libraries . . . . . . . . . . . . . . . . . . . . . . . 215
Item 48: Avoid float and double if exact answers
are required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Item 49: Prefer primitive types to boxed primitives . . . . . . . . . . . 221
Item 50: Avoid strings where other types are more appropriate . . 224
Item 51: Beware the performance of string concatenation . . . . . . 227
Item 52: Refer to objects by their interfaces . . . . . . . . . . . . . . . . . 228
Item 53: Prefer interfaces to reflection . . . . . . . . . . . . . . . . . . . . . 230
Item 54: Use native methods judiciously. . . . . . . . . . . . . . . . . . . . 233
Item 55: Optimize judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Item 56: Adhere to generally accepted naming conventions . . . . . 237

Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Item 57: Use exceptions only for exceptional conditions . . . . . . . 241
Item 58: Use checked exceptions for recoverable conditions
and runtime exceptions for programming errors . . . . . . . 244
Item 59: Avoid unnecessary use of checked exceptions . . . . . . . . 246
Item 60: Favor the use of standard exceptions. . . . . . . . . . . . . . . . 248
Item 61: Throw exceptions appropriate to the abstraction. . . . . . . 250
Item 62: Document all exceptions thrown by each method. . . . . . 252
Item 63: Include failure-capture information in
detail messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Item 64: Strive for failure atomicity . . . . . . . . . . . . . . . . . . . . . . . 256
Item 65: Don't ignore exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 258

Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Item 23: Don't use raw types in new code . . . . . . . . . . . . . . . . . . . 109
Item 24: Eliminate unchecked warnings. . . . . . . . . . . . . . . . . . . . . 116
Item 25: Prefer lists to arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Item 26: Favor generic types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Item 27: Favor generic methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Item 28: Use bounded wildcards to increase API flexibility . . . . . 134
Item 29: Consider typesafe heterogeneous containers . . . . . . . . . . 142

[WHK]

Vaya, se ve muy bueno ese libro, lo buscaré. Me hace mucho sentido lo que dices.

[jhonatanAsm]

patrones gof, tal vez?