[Aporte] Mejores practicas en Java

Iniciado por 3n31ch, 21 Enero 2015, 06:23 AM

0 Miembros y 1 Visitante están viendo este tema.

3n31ch

Hace unos días atrás tuve un problema con el ordenador, de lo aburrido y enojado que estaba borre por error todo sin guardar absolutamente nada. Entre todo ese conjuntos de archivos inútiles se encontraba uno que otro interesante, como es el caso de mis apuntes sobre las mejores practicas en java. No recuerdo todo lo que ahí contenía, pero para evitar que esto me suceda otra vez he decidido publicar lo que recuerdo en este foro, y quizás con su ayuda complementarlo y mejorarlo. Agradecería mucho sus aportes.

(Si un tema similar ya existe por favor no duden en eliminarlo)

Introducción:

Se conocen como buenas practicas la acción de realizar algo preocupándote de que esto este bien hecho, siguiendo patrones, convenciones y estándares adecuados para lograr un buen producto, el tema es que la programación no se queda fuera de este concepto y cada lenguaje tiene sus "buenas practicas". En lo personal concluyo que en Java las "Buenas practicas" no están muy bien definidas y en muchos casos existen variaciones entre lo que uno cree que es bueno y lo que otros creen que lo es. Por esta razón espero que participen y me ayuden a encontrar un punto medio que nos ayude a evitar el temible código espagueti entre otras cosas.

Desarrollo:

1. Nombres:

En java como en muchos otros lenguajes existen variables, paquetes, clases y métodos. Los nombres que identifican a cada uno de estos aun cuando pueden ser prácticamente cualquiera, se establecieron convenciones para que nuestro código fuera mas prolijo y por lo tanto su lectura fuera mas sencilla. Por otro lado aplicando estas practicas se evitaran conflictos tales como que una clase tenga el mismo nombre que un paquete. A continuación listare cada uno de estos acuerdos y mas abajo procederé a detallarlos y adjuntare ejemplos.


1.1. Se recomienda que tanto paquetes, clases, métodos, variables y constantes tengan un nombre significativo que apunte a su utilidad.
1.2. Todas las variables se escriben en minúscula, en caso de tener mas de una palabra se pondrá la inicial de cada una de estas en mayúscula exceptuando la primera.
1.3. El nombre de las constantes sera únicamente en mayúsculas, si existe mas de una palabra estas son separadas por un guion bajo.
1.4. Se recomienda que todos los métodos a lo igual que las variables tengan nombres en minúscula y en caso de existir mas de una palabra, escribir la inicial de cada una de estas con mayúscula exceptuando la primera.
1.5. Se recomienda que los nombres de los métodos siempre sean verbos.
1.6. Utilizar prefijos significativos para métodos comunes.
1.7. Los nombres de las clases siempre empezaran con mayúscula y el resto sera en minúscula, en caso de existir mas de una palabra se pondrá la inicial de cada una de estas con mayúscula.
1.8. Los nombres de paquetes siempre serán totalmente en minúsculas.
1.9. Se recomienda utilizar prefijos tales como "com", "name", "org" para los paquetes dependiendo de quien es su creador.


1.1. Se recomienda que tanto paquetes, clases, métodos, variables y constantes tengan un nombre significativo que apunte a su utilidad:

Hace un tiempo atrás los programadores acostumbraban a utilizar nombres cortos para poder ahorrar memoria, aparte de que muchos editores de texto no aceptaban mas de 80 caracteres por linea, pero actualmente las limitaciones de memoria en disco y memorias portátiles ya se han desvanecido, y prácticamente todo editor de texto soporta con creces mas de 80 caracteres por linea, es por esto que en la actualidad se recomienda siempre dar nombres característicos a cada elemento y de esta manera poder identificar fácilmente cual es su funcionalidad en el programa.

Código (java) [Seleccionar]
// Esto no es recomendado
int w = 640;
int h = 480;

// Esto es recomendado
int width = 640;
int height = 480;


1.2. Todas las variables se escriben en minúscula, en caso de tener mas de una palabra se pondrá la inicial de cada una de estas en mayúscula exceptuando la primera:
Una forma muy simple de identificar una variable de otro tipo de elemento es su nombre, y en java una convención muy conocida es que toda variable empieza en minúscula y en caso de que su nombre se vea compuesto por dos o mas palabras se pondrá la inicial de cada una de estas en mayúscula exceptuando la primera. En el caso de existir una abreviatura tal como FPS se recomienda colocar su nombre en minúsculas de todas maneras.

Código (java) [Seleccionar]
// Esto esta mal
String Saludo = "Hola Mundo";
String MensajeDespedida = "Chao Mundo";
int FPS = 30;


// Esto esta bien
String saludo = "Hola Mundo";
String mensajeDespedida = "Chao Mundo";
int fps = 60;


1.3. El nombre de las constantes sera únicamente en mayúsculas, si existe mas de una palabra estas son separadas por un guion bajo:
Para identificar fácilmente una constante y no tener que buscar su procedencia es muy recomendable poner su nombre completamente en mayúscula y si esta se conforma por mas de una palabra, se separaran con un guion bajo

Código (java) [Seleccionar]
// Esto esta mal
final float pi = 3.14;
final int ESCALAVENTANA = 2;

// Esto esta bien
final float PI = 3.14;
final float ESCALA_VENTANA = 2;


1.4. Se recomienda que todos los métodos a lo igual que las variables tengan nombres en minúscula y en caso de existir mas de una palabra, escribir la inicial de cada una de estas con mayúscula exceptuando la primera:

Código (java) [Seleccionar]
// Esto esta mal

public void PintarPerro(){

}

public void pintar_gato(){

}

// Esto esta bien

public void pintarPerro(){

}

public void pintarGato(){

}



1.5. Se recomienda que los nombres de los métodos siempre sean verbos:
Los métodos usualmente son para realizar acciones, tales como calcular un problema matemático o asignar un nuevo valor a un atributo, es por esta razón que se aconseja que los nombres de los métodos siempre sean verbos tales como pintar, dibujar, calcular, eliminar...

Código (java) [Seleccionar]
// Esto esta mal
public int suma(int x, int y){
return x+y;
}

// Esto esta bien
public int sumar(int x, int y){
return x+y;
}


1.6. Utilizar prefijos significativos para métodos comunes:
Por principio de encapsulación los objetos deberían tener todos sus atributos como privados o protegidos y la única manera de acceder a ellos desde el exterior es por métodos "get" o "set". Se recomienda que siempre que se cree un método con estas características se indique el prefijo "get" o "set" dependiendo de su utilidad.

También existe el prefijo "is" utilizado en métodos que retornan un booleano (true o false) entre otros tales como "compute" para métodos que realicen algún calculo, "find" para métodos destinados a buscar algo, o "initialize" para métodos utilizados para inicializar algo. Estos últimos tres "compute", "find" e "initialize" no son muy utilizados.

Código (java) [Seleccionar]
// Esto esta mal

public void edad(int edad){
this.edad = edad;
}

public int decirEdad(){
return edad;
}

// Esto esta bien
public void setEdad(int edad){
this.edad = edad;
}

public int getEdad(){
return edad;
}

public boolean isFocusable(){
return focusable;
}



1.7. Los nombres de las clases siempre empezaran con mayúscula y el resto sera en minúscula, en caso de existir mas de una palabra se pondrá la inicial de cada una de estas con mayúscula:

Como dije anteriormente una buena manera de identificar ciertos elementos es mediante su nombre y al respetar esta convención nunca tendrás un problema a la hora de identificar una clase de una variable o método.

Código (java) [Seleccionar]
// Esto esta mal
public class juego{

}

public class Ventana_Principal{

}

//Esto esta bien

public class Juego{

}

public class VentanaPrincipal{

}


1.8. Los nombres de paquetes siempre serán totalmente en minúsculas:

los nombres de paquetes serán completamente en minúscula sin importar que exista mas de una palabra, en caso de ser así algunos optan por agregar un "." en mi caso opto por evitar utilizar nombres compuestos, ya que el punto se entiende como un paquete anidado en otro.

Código (java) [Seleccionar]
// Esto esta mal

package Juego;

// Esto esta bien

package juego;



1.9. Se recomienda utilizar prefijos tales como "com", "name", "org" para los paquetes dependiendo de quien es su creador:

Bueno, en este momento me esta costando mucho recordar esto, así que no ahondare mucho en este tema, quizás mas adelante lo complete, el hecho es que existen distintos tipos de prefijos que se acomodan a nosotros como lo son por ejemplos com y name:

com = compañia
name = nombre

En caso de ser un solo programador el que esta programando se utiliza el prefijo name seguido por el nombre del programador y si el programa es por parte de una compañía se utilizaría el prefijo com seguido por el nombre de la compañía, de esta manera se puede identificar quien es su creador y a quien le pertenece los derechos de su creación, un ejemplo para que quede mas claro

Código (java) [Seleccionar]
package name.nacho.components;
package com.polloshermanos.components;


En este caso no pondré una sección "esto esta mal" ya que yo sinceramente no hago mucho uso de esto y no estoy muy familiarizado con su importancia.

Continuare con esto mañana, que ya me estoy cansando de escribir  :xD

Usuario Invitado

Primero que todo, gracias por el aporte. A muchos nóveles les será de ayuda, ya que siempre veo que los principiantes utilizan minúsculas para las clases, PascalCase para los métodos y variables, etc.

Aportando un poco al tema, no es tanto buenas prácticas. Buenas prácticas generalmente se refiere a las técnicas de programación que son eficientes. A lo que acabas de publicar se le suele llamar Convención de nombres y, a lo minúscula seguida de una mayúscula de la primera letra de otra palabra, se le conoce como camelCase. Los nombres de las clases que contienen una mayúscula en cada letra inicial de cada palabra se llama PascalCase.

camelCase:

Código (=java) [Seleccionar]
public void doSomething() {}

PascalCase:

Código (=java) [Seleccionar]
public class MyClass {}
"La vida es muy peligrosa. No por las personas que hacen el mal, si no por las que se sientan a ver lo que pasa." Albert Einstein

3n31ch

#2
Gracias, no sabia lo de camelCaes y PascalCase, lo agregare luego, y como bien dices en es solo convención de nombres, pero lo que intentare hacer es hacer una guía completa, si te das cuenta Nombres es solo el numero 1, el tema es que era mucho texto para escribirlo del tirón u.u.

Gracias por leer mi biblia.

edito:
Teniendo en cuenta que por lo visto ya no puedo modificarlo, intentare recopilar todo lo que encuentre para hacer un nuevo tema, esta vez completo del todo.

~ Yoya ~

Buen post, es bueno tomar este tipo de cosas muy encuentra. Una persona que viole este tipo de reglas fundamentales no lo considero un buen programador.
Mi madre me dijo que estoy destinado a ser pobre toda la vida.
Engineering is the art of balancing the benefits and drawbacks of any approach.

jhonatanAsm

mi primer lenguaje fue ensamblador, tengo 60 años, y no creo que haya sido un error.

- La mayor complejidad de todas es hacer complejo algo que no lo es.

- El inteligente no es aquel que lo sabe todo sino aquel que sabe utilizar lo poco que sabe.

3n31ch

Junto a Gus Garsaky estamos haciendo el post mas completo, nos demoraremos un poco.

PabloPbl

Muy bueno, la mayoría de ellas las aplico en mis programas y he notado que el código queda mas prolijo y legible.

Salu2.

Funkiyo

Gracias por el aporte, eso antes que nada.

Y he de decir que por "tonto" que parezca lo que mas me ha ayudado o me ha puesto a pensar en : Vaya eres medio retard llevas un par de años simplificando nombres en python >.<"

Gracias, el consejo mas sencillo es el que mas me ha ayudado, a veces lo sencillo es lo grande :P.

shellb_c0de

"Tu vida solo es la suma del resto de una ecuación no balanceada, connatural a la programación de Matrix. Eres el producto eventual de una anomalía, que no se ha logrado suprimir de esta armonía de precisión matemática. Aunque sigues siendo una incomodidad que evito con frecuencia, es previsible y no escapa a unas medidas de control que te han conducido inexorablemente aquí.