Visita NetRadio
Sugerencias de Codificación
|
|
|
|
Visita NetRadio Sugerencias de Codificación |
| Anterior | Siguiente |
Quizá el título de la sección esté mal expresado, porque no se intenta aquí establecer una normas a seguir para codificar en Java, sino que en esta sección se recogen las convenciones y sugerencias de codificación Java que sigue Javasoft en su código y que recomienda seguir a la comunidad de programadores. Cubre muchos aspectos, desde los nombres de los ficheros, a la organización de éste, indentación, comentarios, declaraciones, sentencias, espacios en blanco, convenciones de nomenclatura, prácticas de programación, hasta incluso código de ejemplo. Todos los ejemplos de esta sección pertenecen a Sun, tienen su Copyright y se usan con permiso solicitado. Las convenciones son importantes por un gran número de razones, así que ese es el motivo de recogerlas en este Tutorial, aunque cada programador es muy libre de seguirlas o no, dependiendo de sus hábitos ya adquiridos o de las normas que siga su empresa. Entre las razones a destacar por las que se deben seguir una normas, están:
El sufijo de los ficheros con código Java es .java. Un fichero habitual en cada directorio debería ser README, para sumarizar el contenido de ese directorio. Un fichero debe consistir en secciones bien definidas, separadas por líneas en blanco y un comentario opcional identificando cada una de las secciones. Ficheros de más de 2000 líneas con inmanejables y deberían evitarse. El ejemplo de fichero fuente Java, muestra el modo de formatear adecuadamente un fichero. Cada fichero con código Java debe contener una sola clase pública o interfaz. Cuando se asocian clases privadas e interfaces con una clase pública, se pueden colocar en el mismo fichero fuente que la clase pública. La clase pública debería ser la primera clase o interface del fichero. Los ficheros fuente con código Java, deberían seguir el siguiente orden: Todos los ficheros fuente deben comenzar con un comentario al estilo C que indique el programador, o programadores, la fecha, una nota de copyright y una pequeña descripción del propósito del programa. Por ejemplo: /*
* Nombre de la clase
*
* Versión
*
* Copyright
*/
Por ejemplo import java.applet.Applet;
import java.awt.*;
import java.net.*;
Declaraciones de clase e interface En la tabla siguiente se describen las diferentes partes de la declaración de una clase o interface, y en el orden que deben aparecer, tal como se muestra en el código de ejemplo.
Deben tomarse 4 espacios como unidad de indentación. La construcción exacta de la indentación (espacios o tabuladores) no es crítica. Los tabuladores deben estar fijados exactamente cada 8 espacios (no cada 4). Se deben evitar líneas de más de 80 caracteres, porque sino no son manejadas correctamente por muchos terminales y herramientas. Los ejemplos de uso en la documentación deben ir en líneas más cortas, generalmente de no más de 70 caracteres. Cuando una expresión no cabe en una sola línea, debe saltarse a la siguiente línea de acuerdo con los siguientes principios generales:
Estos son algunos ejemplos de saltos de línea en llamadas a métodos: funcion( expresionLarga1, expresionLarga2, expresionLarga3,
expresionLarga4, expresionLarga5 );
var = funcion1( expresionLarga1,
funcion2( expresionLarga2,
expresionLarga3 ) );
Los dos ejemplos siguientes muestran el salto de línea en una expresión aritmética. La primera es la más adecuada, ya que el salto se realiza fuera de la expresión entre paréntesis, que está a más alto nivel. nombreLargo1 = nombreLargo2 * (nombreLargo3 + nombreLargo4 - nombreLargo5)
+ 4 * nombreLargo6; // PREFERIBLE
nombreLargo1 = nombreLargo2 * (nombreLargo3 + nombreLargo4
- nombreLargo5) + 4 * nombreLargo6; // EVITAR
Los ejemplos que siguen muestran la indentación en las declaraciones de métodos. El primer caso es el convencional. El segundo debería desplazar la segunda y tercera líneas demasiado a la derecha si se usa la indentación convencional, así que se indenta solamente 8 espacios. // INDENTACION CONVENCIONAL
unMetodo( int unArg, Object otroArg, String esteEsOtroArg,
Object yTodaviaOtroMas ) {
...
}
// INDENTA 8 ESPACIOS PARA EVITAR UNA INDENTACION DEMASIADO PROFUNDA
private static synchronized otroMetodoConNombreMuyLargo( int unArg,
Object otroArg, String esteEsOtroArg,
Object yTodaviaOtroMas ) {
...
}
El salto de líneas para las sentencias condicionales con if deberían utilizar la regla de los 8 espacios como norma general, en lugar de la habitual de 4 espacios, que en este caso hace la lectura más dificultosa. // NO UTILIZAR ESTA INDENTACION
if ((condicion1 && condicion2)
|| (condicion3 && condicion4)
||!(condicion5 && condicion6)) { // SALTOS ERRONEOS
hacerAlgoAlRespecto(); // HACEN ESTA LINEA CASI INVISIBLE
}
// UTILIZAR ESTA INDENTACION ALTERNATIVA
if ((condicion1 && condicion2)
|| (condicion3 && condicion4)
||!(condicion5 && condicion6)) {
hacerAlgoAlRespecto();
}
// O UTILIZAR ESTA OTRA
if ((condicion1 && condicion2) || (condicion3 && condicion4)
||!(condicion5 && condicion6)) {
hacerAlgoAlRespecto();
}
Las líneas de código siguientes muestran tres ejemplos aceptables de formateo de expresiones ternarias. alpha = (unaExpresionBooleanaMuyLarga) ? beta : gamma;
alpha = (unaExpresionBooleanaMuyLarga) ? beta
: gamma;
alpha = (unaExpresionBooleanaMuyLarga)
? beta
: gamma;
|
|
|
