Este es un recompilado de Best Practices y Convenciones que trato de aplicar diariamente en el codigo que escribo. Quiza es util para ustedes tambien. Hay que recordar que el codigo trabaja con logica matematica, pero los developers no por eso es importante que el codigo no solo sea legible para vos, sino para todo el grupo que trabaja con vos. Simplemente imaginate tratar de modificar codigo que esta escrito en 1 linea OLPL (one line programming language) o metodos de 1000 lineas, es realmente tedioso.Las convenciones en Java son diferentes de C or C#. Voy a postear varias convenciones que me gusta aplicar, pero para ver todas las convenciones de Java podes ir aca.
Las convenciones son necesarias para mantener similitud en el codigo y para ser legible por cualquier miembro de tu grupo, incluso vos mismo. Quiza tu grupo quiera hacer sus propias convenciones, pero yo te aconsejo que sigas los lineamientos de Sun ya que si algun dia cambias de empresa y ellos usan las convenciones oficiales, vas a odiarlos ya que tenes que adaptarte a algo nuevo y no tenes control de nada.

1. Class names

Basicamente Sun dice que las classes tienen que ser Camel Case empezando la primera letra en mayuscula y siguiendo con minusculas hasta el cambio de palabra donde volves a aplicar una mayuscula.
Las classes Java usualmente representan cosas abstractas o concretas, lo que significa que si creas una clase que representa un hospital, no la podes llamar Htal!! es un Hospital !.

Hospital
Patient
RequestDispatcher
StringUtility

2. Nombres de Variable

Lucho dia a dia con mis compaƱeros de trabajo por los nombres de las variables. Parecidos a los nombres de clase, las variables son super importantes ya que son unidades que nos permitiran intuir y entender que hace el programa. La convenciĆ³n Java para las variables es Camel Case tambien pero la primera letra es minuscula.

Veamos el siguiente codigo.

double up = myBean.getUnitPrice();
int q = myBean.getQuantity();
double t = up * q;

Este caso es muy simple, pero imaginemos que quantity, unit price y total son usados en un metodo de 100 lineas de codigo (horrible pero cierto). Seria feo ver esta linea en medio de todo eso, no muchos entenderian esto…

int dp = 20; // discount percentage
if (q > m) {
  t = t * dp / 100;
}

La verdad que si me toca arreglar o modifcar este metodo me voy a querer matar. Tener que buscar que significa t, q y m es tedioso sumando la perdida de tiempo.

Hagamos algo asi…

double unitPrice = myBean.getUnitPrice();
int quantity = myBean.getQuantity();
double total = unitPrice * quantity;
int discountPercentage = 20;
if (quantity && maxAllowed) {
  total = total * discountPercentage / 100;
}

3. Condicionales

Tengo un par de ejemplos con esto, algunos tontos otros no tanto.

3.1. No usar extra codigo

if (latoya.isInsane() ) {
  return this;
} else {
  return that;
}

La segunda parte (else) es totalmente una perdida de tiempo tuyo y del procesador ya que no hay posibilidad de ir al ELSE si el primer IF evalua a TRUE. Yo haria algo asi…

if (latoya.isInsane() ) {
  return this;
}
return that;

3.2. Primera condicion encontrada

if (a < b || b > c) {
  this.execute();
}

Si la primera condicion es valida la segunda nunca va a ser evaluada. Si usas | en vez de || no importa lo que pase, la segunda condicion si va a ser evaluada. Hay casos donde estos operadores son necestarios, pero la realidad muestra que son los menos. El codigo default deberia ser usando doble pipe ||.

Shorthand</strong><br><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; String a = (y == z) ? “this” : that;</span><br><br>Me encanta este shorthand del IF ELSE, pero algunas veces se suele abusar y ahi empieza el <strong>OLPL </strong>(one line programming language) como esto…<br><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; String a = (y == z) ? (x &gt; m) ? true : a &lt; t : (list.size() &gt; x) ……..</span><br><br>Por favor, eviten hacer cosas asi, duelen los ojos solo de mirarlo.<br><strong><br>4. Retorno al inicio</strong><br><br>Un ex jefe mio me odiaba cada vez q yo hacia esto, pero realmente me parece mucho mas claro.<br><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; if (!var.isSomething()) return;</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; String a = this.afunction();</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; more code….</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp; &nbsp;more code….</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp; &nbsp;more code….</span><br><br>El preferia hacer cosas asi, pero yo creo que es menos claro cuales son las condiciones de salida de este statement ya que tenemos que ir al final del codigo para verlo.<br><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; if (var.isSomething()) {</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String a = this.afunction();</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; more code…. &nbsp;</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; } else {</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return;</span><br><span style=”FONT-FAMILY: Courier New”>&nbsp;&nbsp;&nbsp; }</span><br><br>Bueno, esta es la primera entrega de mis best practices en Java, stay tuned!