A qué te refieres con estándares de programación? Porque por ejempo para estilo, a mi me gusta poner la llave que abre en la misma linea que comienza el bloque pero la que cierra en su propio bloque asi:
uso camel-case, o sea nombresDeVariables queComienzanConMinuscula peroLasPalabrasPegadas llevanMayuscula... los nombres de metodos comienzan con minúsculas, los nombres de clases comienzan con mayúsculas... los nombres de paquetes por lo general los manejo a 3 niveles, pero no siempre sigo la misma regla para nombrarlos. Por lo general empiezo con el nombre del cliente o del proyecto (por ejemplo com.solab) y luego el nombre del proyecto (com.solab.iso8583) y ahi van las clases principales; cosas más específicas como clases de conveniencia (métodos de utilería y cosas así) van en un subpaquete y pues trato de agrupar clases por su función, por ejemplo cosas de interfaz gráfica van en el subpaquete y cosas de manejo de conexiones de red van en el subpaquete . La idea es que si alguien más ve la estructura del proyecto, pueda intuir un poco qué cosas están en qué lugares, sin tener que preguntarme.
EDIT: con más tiempo, pongo aquí otras cosas que hago: inicializar siempre las variables locales cuando las declaro, aunque sea a null o a 0; usar siempre bloques para if, while, for, etc aunque sea una sola instrucción lo que sigue (así se evitan muchos problemas cuando de repente le metes un log o println porque estás depurando algo). Eclipse me facilita el hacer los imports más específicos, para la clase que requiero y no usar nunca cosas como que no me gusta porque cuando estás viendo código que no conoces bien y te encuentras con una referencia a una clase que no conoces, si hay puros imports de paquetes completos, luego no sabes a cuál pertenece, en cambio con imports específicos encuentras la clase en los imports y ves a qué paquete pertenece, lo cual luego sirve para saber a qué librería o framework pertenece.
Siempre le pongo comentarios a los métodos, con excepción de los accesores que son demasiado obvios (qué le puedo documentar a un ?). Evito tener métodos demasiado largos, los parto en métodos más cortos, que pueden tener visibilidad menor (protected o incluso private); comento bloques largos explicando lo que hace un ciclo o lo que pasa dentro de un if o else. Cualquier catch debe llevar siempre comentario y manejarse de alguna manera, aunque sea dejando un log de la excepción que ocurrió. Si la excepción no debería manejarse ahí, entonces le pongo throws al método... etc... etc... etc...
Pero hay tantos estándares que no sé si buscabas algun otro tipo de respuesta... y de hecho esto que menciono, más que estándares, son buenas prácticas.
Hola, que tal, gracias por sus respuestas y la respuesta tan detallada de ezamudio, bueno, perdón si no fuí tan claro, realmente me refería a estándares de códficación, justo lo que mencionó ezamudio, cada programador se supone que define su propio estandar. Miren aquí les paso el sugerido por Sun, no se si ya lo hayan visto, pero supongo que tal vez algunos no.
como de qué tipo?
A qué te refieres con estándares de programación? Porque por ejempo para estilo, a mi me gusta poner la llave que abre en la misma linea que comienza el bloque pero la que cierra en su propio bloque asi:
uso camel-case, o sea nombresDeVariables queComienzanConMinuscula peroLasPalabrasPegadas llevanMayuscula... los nombres de metodos comienzan con minúsculas, los nombres de clases comienzan con mayúsculas... los nombres de paquetes por lo general los manejo a 3 niveles, pero no siempre sigo la misma regla para nombrarlos. Por lo general empiezo con el nombre del cliente o del proyecto (por ejemplo com.solab) y luego el nombre del proyecto (com.solab.iso8583) y ahi van las clases principales; cosas más específicas como clases de conveniencia (métodos de utilería y cosas así) van en un subpaquete
y pues trato de agrupar clases por su función, por ejemplo cosas de interfaz gráfica van en el subpaquete
y cosas de manejo de conexiones de red van en el subpaquete
. La idea es que si alguien más ve la estructura del proyecto, pueda intuir un poco qué cosas están en qué lugares, sin tener que preguntarme.
EDIT: con más tiempo, pongo aquí otras cosas que hago: inicializar siempre las variables locales cuando las declaro, aunque sea a null o a 0; usar siempre bloques para if, while, for, etc aunque sea una sola instrucción lo que sigue (así se evitan muchos problemas cuando de repente le metes un log o println porque estás depurando algo). Eclipse me facilita el hacer los imports más específicos, para la clase que requiero y no usar nunca cosas como
que no me gusta porque cuando estás viendo código que no conoces bien y te encuentras con una referencia a una clase que no conoces, si hay puros imports de paquetes completos, luego no sabes a cuál pertenece, en cambio con imports específicos encuentras la clase en los imports y ves a qué paquete pertenece, lo cual luego sirve para saber a qué librería o framework pertenece.
Siempre le pongo comentarios a los métodos, con excepción de los accesores que son demasiado obvios (qué le puedo documentar a un
?). Evito tener métodos demasiado largos, los parto en métodos más cortos, que pueden tener visibilidad menor (protected o incluso private); comento bloques largos explicando lo que hace un ciclo o lo que pasa dentro de un if o else. Cualquier catch debe llevar siempre comentario y manejarse de alguna manera, aunque sea dejando un log de la excepción que ocurrió. Si la excepción no debería manejarse ahí, entonces le pongo throws al método... etc... etc... etc...
Pero hay tantos estándares que no sé si buscabas algun otro tipo de respuesta... y de hecho esto que menciono, más que estándares, son buenas prácticas.
Error de comunicación
Yo tampoco entendí la pregunta, y al igual que ezamudio utilizo los estándares de camel-case, identación, paquetes, etc...
Pero casi estoy seguro de que no te referías a eso... :-S
Sun Code Conventions
Hola.
Si la pregunta se refiere a estandares de codificacion java yo sigo las Sun Code Conventions.
Si se refiere a lineamientos de programacion sigo algunas que se mencionan en el libro pragmatic programmer http://www.pragprog.com/the-pragmatic-programmer/extracts/tips. y algunos principios de diseño y codificacion que se mencionan en este libro http://mercury.flazx.net/preview/b1974a/flazx_sun-certified-programmer-developer-for-java-2-study-guide-exam-310-035-310-027-.zip.
Saludos
Hola, que tal, gracias por
Hola, que tal, gracias por sus respuestas y la respuesta tan detallada de ezamudio, bueno, perdón si no fuí tan claro, realmente me refería a estándares de códficación, justo lo que mencionó ezamudio, cada programador se supone que define su propio estandar. Miren aquí les paso el sugerido por Sun, no se si ya lo hayan visto, pero supongo que tal vez algunos no.