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
Mostrar Mensajes
