Reglas de programación de Java Versión 6.3, enero de 2011

Servicios Geotécnicos Software Copyright © 1998 - 2011

Este documento está disponible en http://geosoft.no/development/javastyle.html

Tabla de Contenido 1 Introducción 1.1 Estructura de las Recomendaciones 1.2 Recomendaciones Importancia 1.3 Comprobación automática de Estilo

2 Recomendaciones generales

3 Convenciones de nomenclatura 3.1 Convenciones generales de nomenclatura 3.2 Convenciones de nombres específicos

4 Archivos

5 Estados 5,1 de paquetes y sentencias de importación 5.2 Clases e Interfaces 5.3 Modalidades 5.4 Tipos 5.5 Variables 5,6 Loops 5.7 Condicionales 5,8 Varios

6 Presentación y Comentarios 6.1 Diseño 6.2 El espacio en blanco 6,3 Comentarios

7 Referencias

1 Introducción Este documento enumera las recomendaciones de codificación Java comunes en el desarrollo de la comunidad Java.

Las recomendaciones se basan en las normas establecidas recogidos de un número de fuentes, la experiencia individual, requisitos / necesidades locales, así como sugerencias dadas en [1] , [2] , [3] , [4] y [5] .

Hay varias razones para la introducción de una nueva directriz y no sólo en referencia a los anteriores. La razón principal es que estas guías son demasiado generales en su alcance y que las reglas más específicas (especialmente las normas de denominación) deben ser establecidos. Asimismo, la presente guía tiene una forma anotada que hace que sea más fácil de usar durante las revisiones de código del proyecto que la mayoría de las directrices existentes. Además, las recomendaciones de programación en general, tienden a mezclar los problemas de estilo con problemas de lenguaje técnico de una manera un tanto confusa. El presente documento no contiene todas las recomendaciones técnicas de Java en absoluto, sino que se centra principalmente en el estilo de programación.

Mientras que un entorno de desarrollo dado (IDE), puede mejorar la legibilidad del código de acceso por la visibilidad, codificación de color, el formato automático y así sucesivamente, el programador no debe confiar en tales características. El código fuente se debe considerar siempre más grande que el IDE se desarrolla dentro y debe ser escrito de una manera que maximice su lectura independiente de cualquier IDE.

1.1 Estructura de las Recomendaciones.

Las recomendaciones están agrupadas por tema y cada recomendación se numera para que sea más fácil referirse a durante las revisiones.

Disposición para las recomendaciones es el siguiente:

n. Guía breve descripción Ejemplo si es aplicable La motivación, la formación y la información adicional.

La sección de la motivación es importante. Los estándares de codificación y pautas tienden a empezar "guerras de religión", y es importante señalar los antecedentes de la recomendación.

Recomendación 1.2 Importancia

En las secciones de orientación de los términos debe, puede y debe tener un significado especial. Un requisito imprescindible debe ser seguido, a deben es una recomendación fuerte, y una lata es una pauta general.

1.3 Comprobación automática de Estilo

Muchas herramientas ofrecen la comprobación automática de código del estilo. Uno de el más popular y rica característica es Checkstyle por Oliver Burn.

Checkstyle se configura a través de un archivo XML de reglas de estilo que se aplica al código fuente. Es muy útil si se integra en el proceso de construcción o el entorno de desarrollo. Hay plugins Checkstyle para todos los IDEs más populares disponibles.

Para utilizar Checkstyle con las reglas de estilo Geosoft a continuación, utilizar el archivo de configuración: geosoft_checks.xml .

2 Recomendaciones generales 1. Cualquier violación a la guía si se permite que mejora la legibilidad. El principal objetivo de la recomendación es para facilitar la lectura y por lo tanto la comprensión y la facilidad de mantenimiento y la calidad general del código. Es imposible cubrir todos los casos específicos en una guía general y el programador debe ser flexible.

3 Convenciones de nomenclatura 3.1 Convenciones generales de nomenclatura

2. Nombres que representan los paquetes deben estar en minúsculas. mypackage, com.company.application.ui Paquete de convención de nomenclatura utilizada por Sun para los paquetes básicos de Java. El nombre del paquete inicial que representa el nombre de dominio debe estar en minúsculas. 3. Nombres que representan los tipos deben ser sustantivos y escrito en mayúsculas y minúsculas comenzando con mayúscula. Line, AudioSystem La práctica común en la comunidad de desarrollo de Java y también la convención de nomenclatura tipo utilizado por Sun para los paquetes básicos de Java. 4. Los nombres de variables deben estar en mayúsculas y minúsculas comenzando con minúscula. línea, AudioSystem La práctica común en la comunidad de desarrollo de Java y también la convención de nombres para las variables usadas por Sun para los paquetes básicos de Java. Hace que las variables fáciles de distinguir de los tipos, y resuelve eficazmente posible colisión de nombres como en la línea línea de declaración; 5. Nombres que representan constantes (variables final) debe estar en mayúsculas utilizando subrayado para separar palabras.

MAX_ITERATIONS, Color_Red La práctica común en la comunidad de desarrollo de Java y también la convención de nomenclatura utilizada por Sun para los paquetes básicos de Java.

En general, el uso de constantes debe reducirse al mínimo. En muchos casos la aplicación del valor como un método es una mejor elección:

getMaxIterations int () / / No: MAX_ITERATIONS = 25 { volver 25; }

Esta forma es más fácil de leer, y garantiza una interfaz uniforme a los valores de la clase. 6. Nombres que representan los métodos deben ser verbos y escrito en mayúsculas y minúsculas comenzando con minúscula. getName (), computeTotalWidth () La práctica común en la comunidad de desarrollo de Java y también la convención de nomenclatura utilizada por Sun para los paquetes básicos de Java. Esto es idéntico a los nombres de variables, pero los métodos en Java son ya distinguibles de las variables por su forma específica. 7. Abreviaturas y siglas no deben estar en mayúsculas cuando se usa como nombre. exportHtmlSource (); / / NO: exportHTMLSource (); openDvdPlayer (); / / NO: openDVDPlayer (); Uso mayúsculas para el nombre de base se dan en conflicto con las convenciones de nombres dados anteriormente. Una variable de este tipo whould tiene que ser nombrado dDV, HTML, etc que obviamente no es muy legible. Otro problema se ilustra en los ejemplos anteriores; Cuando el nombre está conectado a otro, la legibilidad se reduce seriamente; La palabra tras el acrónimo no destaca como debería. 8. Las variables privadas de la clase debería haber subrayado sufijo. class Person {private String name_; ... } Aparte de su nombre y su tipo, el alcance de una variable es su característica más importante. Indicando ámbito de la clase mediante el uso de relieve hace que sea fácil distinguir las variables de clase a partir de variables scratch locales. Esto es importante porque las variables de clase se considera que tienen mayor significación de variables del método, y debe tratarse con especial cuidado por el programador.

Un efecto secundario de la convención de nomenclatura subrayado es que muy bien se resuelve el problema de encontrar razonables nombres de variable para métodos de establecimiento:

vacío setName (String nombre) { name_ = nombre; }

Una cuestión es si el guión bajo se debe agregar como prefijo o como sufijo. Ambas prácticas son de uso general, pero este último es recomendable porque parecen conservar mejor la lectura del nombre.

Cabe señalar que la identificación alcance en las variables han sido un tema controvertido desde hace bastante tiempo. Parece, sin embargo, que esta práctica ahora está ganando adeptos y que cada vez es más y más común como una convención en la comunidad de desarrollo profesional. 9. Las variables genéricas deben tener el mismo nombre que su tipo. vacío setTopic (tema Tema) / / NO: setTopic vacío (valor Topic) / / NO: setTopic vacío / / NO (Tema atópica): void setTopic (Tema t) void connect (base de datos de base de datos) / / NO: void connect (Base de datos db) / / NO: void connect (Base de datos oracledb) Reducir la complejidad al reducir el número de términos y nombres utilizados. También hace fácil deducir el tipo dado un nombre de variable única.

Si por alguna razón esta convención no parece encajar es una fuerte indicación de que el nombre del tipo es mal elegido.

No genéricas variables tienen un papel importante. Estas variables pueden a menudo ser identificado mediante la combinación de papel y escriba:

Punto startingPoint, CenterPoint; Nombre loginName;

10. Todos los nombres deben ser escritos en Inglés. Inglés es el idioma preferido para el desarrollo internacional. 11. Las variables con un ámbito de aplicación general deben tener nombres largos, las variables con un alcance pequeño puede tener nombres cortos [1] . Las variables virtual utilizada para el almacenamiento temporal o índices son más cortos. Un programador de la lectura de variables tales deben ser capaces de asumir que su valor no se utiliza fuera de unas pocas líneas de código. Variables comunes reutilizables para enteros i son, j, k, m, n y para caracteres c y d. 12. El nombre del objeto es implícito, y se debe evitar en un nombre de método. line.getLength (); / / NO: line.getLineLength (); Este último podría parecer natural en la declaración de la clase, pero resulta superfluo en uso, como se muestra en el ejemplo.

3.2 Convenciones de nomenclatura específicas

13. Los términos get / set debe utilizarse cuando un atributo que se accede directamente. employee.getName (); employee.setName (nombre); matrix.getElement (2, 4); matrix.setElement (2, 4, valor); La práctica común en la comunidad de Java y la convención utilizada por Sun para los

paquetes básicos de Java. 14. Es prefijo debe ser utilizado para las variables booleanas y métodos. isSet, isVisible, isFound isFinished, isOpen Esta es la convención de nomenclatura para métodos y variables booleanas utilizadas por Sun para los paquetes básicos de Java.

Con el prefijo es resuelve un problema común de elegir mal los nombres lógicos como el estatus o la bandera. IsStatus isFlag o simplemente no encaja, y el programador se ve obligado a escoger los nombres más significativos.

Métodos de establecimiento de las variables booleanas debe haber configurado como prefijo en:

vacío setFound (booleano isFound);

Hay algunas alternativas al prefijo es que encaja mejor en algunas situaciones. Estas son las tiene, puede y debe prefijos:

hasLicense boolean (); booleano canEvaluate (); booleano shouldAbort = false;

15. El término compute puede utilizarse en métodos donde algo se computado. valueSet.computeAverage (); matrix.computeInverse () Dar al lector la idea de inmediato que se trata de una operación que consume tiempo potencial, y si se utiliza repetidamente, se podría considerar el almacenamiento en caché el resultado. El uso constante del término mejora la legibilidad. 16. El término encontrar se puede utilizar en métodos en los que algo se busca. vertex.findNearestVertex (); matrix.findSmallestElement (); node.findShortestPath (Nodo DestinationNode); Dar al lector la idea de inmediato que se trata de una simple mirada a método con un mínimo de cálculos involucrados. El uso constante del término mejora la legibilidad. 17. La inicialización término puede ser usado donde un objeto o un concepto se ha establecido. printer.initializeFontSet (); La inicialización americano se prefiere en la inicialización de Inglés. Abreviatura init debe ser evitado. 18. JFC (Java Swing) variables deben incluir el sufijo del tipo de elemento. widthScale, nameTextField, mainPanel leftScrollbar,, fileToggle, minLabel, printerDialog Mejora la legibilidad ya que el nombre da al usuario una idea inmediata del tipo de la variable y de ese modo los recursos disponibles del objeto. 19. Forma plural se debe utilizar en los nombres que representan una colección de objetos. Los puntos de recogida <PUNTO>; int [] valores; Mejora la legibilidad ya que el nombre da al usuario una idea inmediata del tipo de la

variable y las operaciones que se pueden realizar en sus elementos. 20. Prefijo n debe ser utilizado para variables que representan un número de objetos. NPOINTS, nlines La notación se toma de las matemáticas en el que es una convención establecida para indicar un número de objetos.

Tenga en cuenta que el uso dom prefijo num en los paquetes básicos de Java para dichas variables. Esto probablemente se entiende como una abreviatura del número de, pero a medida que se parece más a número tiene el nombre de variable extraño y engañoso. Si "número de" es la frase preferida, prefijo Númerode se puede utilizar en lugar de n. Prefijo de número no debe ser utilizado. 21. No sufijo debe ser utilizado para variables que representan un número de entidad. Tableño, employeeNo La notación es tomado de las matemáticas, donde es una convención establecida para indicar un número de entidad.

Una alternativa elegante a las variables de este tipo con un prefijo i: ITable, IEmployee. Esto efectivamente hace que sean iteradores con nombre. 22. Las variables Iterator se llama i, j, k, etc para (Iterator i = points.iterator (); i.hasNext ();) {:} for (int i = 0; i <nTables, i + +) {:} La notación es tomado de las matemáticas, donde es una convención establecida para indicar iteradores.

Variables que j, k, etc debe ser utilizado para bucles anidados solamente. 23. Nombres complemento debe ser utilizado para las entidades de complemento [1] . get / set, añadir / eliminar, crear / destruir, start / stop, insertar / eliminar, incremento / decremento, viejo / nuevo comienzo / final, primer / último, arriba / abajo, min / max, siguiente / anterior, viejo / nuevo, abrir / cerrar, mostrar / ocultar, suspender / reanudar, etc Reducir la complejidad de simetría. 24. Las abreviaturas en los nombres debe ser evitado. computeAverage (); / / NO: compAvg (); ActionEvent evento, / / NO: e ActionEvent; catch (Exception Excepción) {/ / NO: catch (Exception e) { Hay dos tipos de palabras a considerar. En primer lugar están las palabras comunes que se enumeran en un diccionario de la lengua. Estos nunca deben ser abreviados. Nunca escriba:

cmd en lugar de comando borrador en lugar de calcular cp en lugar de la copia e en lugar de excepción init en lugar de inicializar

pt en vez de punto etcétera

Entonces hay frases específicas de dominio que son naturalmente más conocidos por su acrónimo o abreviaturas. Estas frases deben mantenerse abreviado. Nunca escriba:

HypertextMarkupLanguage en lugar de html CentralProcessingUnit en lugar de la CPU PriceEarningRatio en lugar de pe etcétera 25. Negada nombres de las variables booleanas deben ser evitados. bool isError; / / NO: isNoError bool isFound / / NO: isNotFound El problema surge cuando el operador lógico no se utiliza y doble negación se presenta. No es inmediatamente evidente qué! IsNotError significa. 26. Constantes asociados (variables final) debe estar precedido por un nombre de tipo común. int último Color_Red = 1; COLOR_GREEN final int = 2; COLOR_BLUE final int = 3; Esto indica que las constantes pertenecen juntos, y representa lo que las constantes de concepto.

Una alternativa a este enfoque es poner las constantes dentro de una interfaz eficaz anteponiendo sus nombres con el nombre de la interfaz:

Color de interfaz { RED final int = 1; GREEN final int = 2; BLUE final int = 3; }

27. Clases de excepción debe ser con el sufijo Exception. AccessException clase extends Exception {:} Clases de excepción no son realmente parte del diseño principal del programa, y nombrarlos como este hace destacar con respecto a las otras clases. Esta norma es seguida por Sun en la biblioteca básica de Java. 28. Las implementaciones por defecto de la interfaz puede ir precedido por defecto. DefaultTableCellRenderer clase implementa TableCellRenderer {:} No es poco común para crear una implementación de la clase simplista de una interfaz que proporciona el comportamiento por defecto para los métodos de interfaz. La convención de prefijar estas clases por defecto ha sido aprobado por Sun para la biblioteca de Java. 29. Clases Singleton debe devolver su única instancia a través del método getInstance. clase UnitManager {private final static UnitManager instance_ = new UnitManager (); UnitManager privado () {... } Public static UnitManager getInstance () / / NO: get () o ejemplo () o unitManager () {return etc instance_;}}

La práctica común en la comunidad de Java aunque no siempre seguida de Sol en el JDK. La disposición anterior es el patrón preferido. 30. Las clases que se crean instancias en nombre de otros (fábricas) puede hacerlo a través del método nuevo [ClassName] clase PointFactory {Newpoint pública Point (...) {... }} Indica que la instancia se crea de nuevo en el método de la fábrica y que la construcción es un reemplazo controlado de nuevo Punto (). 31. Las funciones (métodos devuelven un objeto) debe ser el nombre de lo que regresar y procedimientos (métodos void) después de lo que hacen. Aumentar la legibilidad. Hace que sea más claro lo que el equipo debe hacer y sobre todo todas las cosas que no se supone que debe hacer. De nuevo, esto hace que sea más fácil de mantener el código limpio de efectos secundarios.

4 Archivos 32. Archivos fuente de Java debe tener la extensión. Java. Point.java Forzadas por las herramientas de Java. 33. Las clases deben ser declarados en archivos individuales con el nombre del archivo que coincida con el nombre de la clase. Secundaria clases particulares pueden ser declaradas como clases internas y residir en el archivo de la clase a la que pertenecen. Forzadas por las herramientas de Java. 34. Contenido del archivo debe mantenerse dentro de 80 columnas. 80 columnas es la dimensión común para los editores, emuladores de terminales, impresoras y depuradores, y los archivos que se comparten entre varios desarrolladores deben mantener dentro de estas limitaciones. Mejora la legibilidad cuando se rompe no intencionales de la línea se evitan cuando se pasa de un archivo entre los programadores. 35. Los caracteres especiales como pausa TAB y la página debe ser evitado. Estos personajes están obligados a causar problema para los editores, impresores emuladores de terminal, o depuradores cuando se utiliza en un programador multi-, el medio ambiente multi-plataforma. 36. El carácter incompleto de líneas de división debe hacerse evidente [1] . totalSum = a + b + c + d + e; método (param1, param2, param3); setText ("Larga cola dividir" + "en dos partes."); for (int Tableño = 0; Tableño <nTables; Tableño + = tableStep) {... } Las líneas de división se produce cuando una instrucción exceder el límite de columna 80 dado anteriormente. Es difícil dar reglas rígidas para el número de líneas debe ser dividido, pero los ejemplos anteriores deberían dar una pista general.

En general:

Romper después de una coma. Descanso después de un operador.

Alinear la nueva línea con el principio de la expresión en la línea anterior.

5 Estados 5,1 de paquetes y sentencias de importación

37. La declaración de paquetes debe ser la primera instrucción del expediente. Todos los archivos deben pertenecer a un paquete específico. La ubicación declaración paquete impuesto por el lenguaje Java. Dejar que todos los archivos pertenecen a un real (en lugar de la predeterminada Java) hace cumplir paquete Java técnicas de programación orientada a objetos del lenguaje. 38. Las declaraciones de importación debe seguir la instrucción package. Declaraciones de importación se clasifican con los primeros paquetes más fundamentales, y se agrupan en paquetes asociados entre sí y una línea en blanco entre los grupos. java.io.IOException importación; java.net.URL importación; java.rmi.RmiServer importación; java.rmi.server.Server importación; javax.swing.JPanel importación; javax.swing.event.ActionEvent importación, importación org.linux . apache.server.SoapServer; La ubicación declaración de importación impuesto por el lenguaje Java. La clasificación hace que sea sencillo para navegar por la lista cuando hay muchas importaciones, y hace que sea fácil determinar los dependiencies del paquete actual La agrupación reducir la complejidad por el colapso de la información relacionada en una unidad común. 39. Clases importadas siempre debe aparecer de forma explícita. java.util.List importación; / / NO: java.util import *; java.util.ArrayList importación, importación java.util.HashSet;. Importación de clases explícitamente da un valor excelente documentación para la clase a la mano y hace la clase más fácil de comprender y mantener.

Herramientas apropiadas deben ser utilizados con el fin de mantener siempre la lista de importación mínimo y hasta la fecha.

5.2 Clases e Interfaces

40. Declaraciones de clases e interfaces deben organizarse de la siguiente manera:

1. Clase / Interface documentación. 2. clase o declaración de interfaz. 3. De clase (estáticos) variables en el orden público, proteger, paquete

(sin modificador de acceso), privado. 4. Las variables de instancia en el orden público, proteger, paquete (sin

modificador de acceso) y privada.

5. Constructores. 6. Los métodos (sin ningún orden específico).

Reducir la complejidad por lo que la ubicación de cada elemento de la clase predecible.

5.3 Modalidades

41. Modificadores método debe ser dado en el orden siguiente: <access> abstracto estático sincronizado nativo último <unusual> El modificador <access> (si está presente) debe ser el primer modificador. plaza pública estática doble (double a); / / NO: static public double cuadrado (double a); <access> es uno de los públicos, protegidos o privados mientras <unusual> incluye volátiles y transitorias. La lección más importante aquí es mantener el modificador de acceso como el primer modificador. De los posibles modificadores, esto es, con mucho, el más importante, y debe destacarse en la declaración de método. Para los otros modificadores, el orden es menos importante, pero tiene sentido tener una convención fija.

5.4 Tipos

42. Conversiones de tipos debe realizarse siempre de forma explícita. Nunca confíe en la conversión de tipos implícita. floatValue = (int) intValue; / / NO: floatValue = intValue; Por ello, el programador indica que es consciente de los diferentes tipos involucrados y que la combinación es intencional. 43. Especificadores de matriz debe ser unido con el tipo no la variable. int [] a = new int [20]; / / NO: int a [] = new int [20] El arrayness es una función del tipo de base no, la variable. No se sabe por qué Sun permite a ambas formas.

5.5 Variables

44. Las variables se deben inicializar en el que se declaran y deben declararse en el ámbito más pequeño posible. Esto asegura que las variables son válidas en cualquier momento. A veces no es posible inicializar una variable a un valor válido en el que se ha declarado. En estos casos se debe dejar sin inicializar en lugar de inicializa a un valor falso. 45. Variables nunca debe tener un significado doble. Mejora la legibilidad al asegurar que todos los conceptos están representados de forma exclusiva. Reducir la probabilidad de error por efectos secundarios. 46. Las variables de clase nunca debe ser declarado público. El concepto de ocultación de información y encapsulación Java es violado por las variables públicas. Usar variables y funciones privadas de acceso en su lugar. Una

excepción a esta regla es cuando la clase es esencialmente una estructura de datos, sin comportamiento (lo que equivale a una C + + struct). En este caso, es conveniente poner a las variables de la clase de instancia pública [2] . 47. Las matrices deben declararse con sus paréntesis junto al tipo. double [] vértice; / / NO: doble vértice [], int [] Count / / NO: int cuenta; [] public static void main (String [argumentos]) public double computeVertex [] () La razón de es doble. En primer lugar, la matriz-ness es una función de la clase, no de la variable. En segundo lugar, al devolver una matriz de un método, no es posible tener los soportes con excepción del de tipo (como se muestra en el ejemplo anterior). 48. Las variables deben ser mantenidos vivos durante el menor tiempo posible. Mantener las operaciones en una variable dentro de un alcance pequeño, es más fácil controlar los efectos y efectos secundarios de la variable.

5,6 Loops

49. Sólo los estados de control de bucle debe ser incluido en la construcción para (). sum = 0; / / NO: for (i = 0, suma = 0; i <100; i + +) for (i = 0; i <100; i + +) suma + = valor [i]; sum + = valor [i ]; Aumentar la mantenibilidad y la legibilidad. Hacer una distinción clara de lo controla y lo que está contenido en el bucle. 50. Variables de bucle debe ser inicializada inmediatamente antes del bucle. isDone = false; / / NO: bool isDone = false; while (isDone!) {/ / :: / / while {} / / (isDone!): / /} 51. El uso de do-while bucles pueden ser evitados. do-while bucles son menos legibles que los bucles mientras ordinarios y para los bucles desde el condicional es en la parte inferior del bucle. El lector debe escanear todo el bucle con el fin de comprender el alcance del bucle.

Además, el do-while no son necesarios. Cualquier do-while puede ser reescrito en un bucle while o un bucle for. La reducción del número de construcciones utilizadas mejorar readbility. 52. El uso de romper y continuar en bucles debe ser evitado. Estas declaraciones sólo se debe utilizar si se demuestra que den una mayor facilidad de lectura que sus homólogos estructurados.

5.7 Condicionales

53. Complejas expresiones condicionales debe ser evitada. Introducir temporales variables booleanas en lugar [1] . bool isFinished = (elementNo <0) | | (elementNo> maxelement); isRepeatedEntry bool = elementNo == lastElement; if (isFinished | | isRepeatedEntry) {:} / / NO: if ((elementNo <0) | | (elementNo> maxelement) | | elementNo lastElement ==) {:} Mediante la asignación de variables booleanas a las expresiones, el programa obtiene

documentación automática. La construcción será más fácil de leer, depurar y mantener. 54. El caso nominal debe ser puesto en la si-parte y la excepción en la parte else de una sentencia if [1] . booleano Isok = readFile (fileName); if (Isok) {:} else {:} Se asegura de que las excepciones no oscurece el camino normal de ejecución. Esto es importante tanto para la legibilidad y el rendimiento. 55. El condicional se debe poner en una línea separada. if (isDone) / / NO: if (isDone) doCleanup (); doCleanup (); Esto es para propósitos de depuración. Al escribir en una sola línea, no está claro si la prueba es realmente cierto o no. 56. Sentencias ejecutables en los condicionales deben ser evitados. InputStream stream = File.open (filename, "w"); if (corriente = null!) {:} / / NO: if (File.open (filename, "w") = null!)) {:} Condicionales con instrucciones ejecutables son simplemente muy difícil de leer. Esto es especialmente cierto para los nuevos programadores de Java.

5,8 Varios

57. El uso de números mágicos en el código debe ser evitado. Números distintos de 0 y 1 pueden ser considerados como constantes con nombre declarado en su lugar. private static final int TEAM_SIZE = 11;: El jugador [] = new jugadores Player [TEAM_SIZE] / / NO: El jugador [] = new jugador jugadores [11]; Si el número no tiene un significado evidente por sí misma, la legibilidad se mejora mediante la introducción de una constante denominada en su lugar. 58. Constantes de punto flotante siempre debe ser escrito con punto decimal y un decimal como mínimo. doble total = 0,0; / / NO: total doble = 0; doble velocidad = 3.0e8 / / NO: doble velocidad = 3e8, suma doble;: = suma (a + b) * 10,0; Este énfasis en la naturaleza diferente de los números enteros y de punto flotante. Matemáticamente los dos conceptos completamente diferentes modelos y no compatibles.

También, como en el último ejemplo anterior, se destaca el tipo de la variable asignada (suma) en un punto en el código donde esto podría no ser evidente. 59. Constantes de punto flotante siempre se debe escribir con un dígito antes del punto decimal. doble total = 0,5; / / NO: total doble = .5; El número y el sistema de expresión en Java está tomado de las matemáticas y uno debe adherirse a las convenciones matemáticas de sintaxis siempre que sea posible. También, 0,5 es mucho más fácil de leer que .5; No hay manera de que se puede mezclar con el entero 5. 60. Las variables estáticas o métodos siempre deben ser referidos a través del nombre de la clase y no a través de una variable de instancia. Thread.sleep (1000), / / NO: Thread.Sleep (1000);

Esta destacar que las referencias de elementos es estático e independiente de cualquier instancia particular. Por la misma razón el nombre de clase debe incluirse también cuando una variable o método se accede desde dentro de la misma clase.

6 Presentación y Comentarios 6.1 Diseño

61. Hendidura básica debe ser 2. for (i = 0; i <nElements, i + +) a [i] = 0; La sangría se utiliza para enfatizar la estructura lógica del código. Sangría de 1 es demasiado pequeña para lograr esto. La sangría de más de 4 hace que el código profundamente anidado difícil de leer y aumentar la posibilidad de que las líneas se deben dividir. La elección entre indentación de 2, 3 y 4; 2 y 4 son los más comunes, y 2 a disminuir la probabilidad de líneas de código de división. Tenga en cuenta que la recomendación de Sun en este punto es 4. 62. Diseño de bloque debe ser como se ilustra en el ejemplo 1 a continuación (recomendado) o ejemplo 2, y no debe ser como se muestra en el ejemplo 3. Bloques de clase, interfaz y método debe utilizar el diseño de bloque del ejemplo 2. while (hecho!) {doSomething (); moreToDo hecho = ();}

while (hecho!) {doSomething (); moreToDo hecho = ();}

while (hecho!) {doSomething (); moreToDo hecho = ();}

Ejemplo 3 introducir un nivel de indentación adicional que no hace hincapié en la estructura lógica del código tan claramente como ejemplo 1 y 2. 63. Las declaraciones de clase y la interfaz debe tener la siguiente forma: Rectángulo clase amplía Shape implementa Cloneable, Serializable {... } Esto se deduce de la regla general de bloques anteriormente. Nótese que es común en la comunidad de desarrolladores Java para que el soporte de abertura en el extremo de la línea de la clase de palabras clave. Esto no es recomendable. 64. Definiciones de método debe tener la siguiente forma: algunMetodo public void () throws SomeException {... } Véase el comentario sobre las declaraciones de clases anteriores. 65. La clase if-else de los estados deben tener la siguiente forma: if (condición) {sentencias;} if (condición) {sentencias;} else {sentencias;} if (condición) {sentencias;} else if (condición) {sentencias;} else {sentencias;} Esto se deriva en parte de la regla general de bloques anteriormente. Sin embargo, se podría examinar si una cláusula else debe estar en la misma línea que el corchete de cierre de la anterior cláusula if o else: if (condición) { declaraciones; } Else { declaraciones; }

Esto es equivalente a la recomendación dom El enfoque elegido se considera mejor en la forma en que cada parte de la instrucción if-else está escrito en líneas

separadas del archivo. Esto debería hacer que sea más fácil manipular el estado, por ejemplo cuando se mueve alrededor de cláusulas else. 66. La declaración de debe tener la forma siguiente: for (inicialización; condición; actualización) {sentencias;} Esto se deduce de la regla general de bloques anteriormente. 67. Un vacío de declaración debe tener la siguiente forma: for (inicialización; condición; actualización); Este énfasis en el hecho de que la declaración de está vacío y que hace que sea obvio para el lector que esto es intencional. 68. La sentencia while debería tener la siguiente forma: while (condición) {sentencias;} Esto se deduce de la regla general de bloques anteriormente. 69. La sentencia do-while debería tener la siguiente forma: do {sentencias;} while (condición); Esto se deduce de la regla general de bloques anteriormente. 70. La sentencia switch debería tener la siguiente forma: switch (estado) {case ABC: Declaraciones / / DEF Fallthrough caso: declaraciones; break; XYZ caso: declaraciones; break; default: sentencias; break;} Esto difiere ligeramente de la recomendación sol tanto en la sangría y el espaciado. En particular, cada palabra clave caso se sangra con respecto a la declaración del interruptor como un todo. Esto hace que la sentencia switch entero se destacan. Tenga en cuenta también el espacio extra antes del: el carácter. El comentario explícito Fallthrough deben incluirse cada vez que hay una sentencia case sin una sentencia break. Saliendo de la rotura de la salida es un error común, y debe quedar claro que es intencional cuando no está allí. 71. Una sentencia try-catch debería tener la siguiente forma: try {sentencias;} catch (Exception Excepción) {sentencias;} try {sentencias;} catch (Exception Excepción) {sentencias;} finally {sentencias;} Esto se deriva en parte de la regla general de bloques anteriormente. Esta forma difiere de la recomendación dom de la misma manera como la instrucción if-else se ha descrito anteriormente. 72. Sola sentencia if-else, for o while declaraciones se puede escribir sin paréntesis. if (condición) instrucción; while (condición) instrucción; for (inicialización; condición; update) declaración; Es una recomendación común (Sun Java recomendación incluido) que los soportes siempre se debe utilizar en todos estos casos. Sin embargo, los soportes son, en general, una construcción del lenguaje que los grupos de varias declaraciones. Los paréntesis son por definición superfluo en una sola sentencia. Un argumento común en contra de esta sintaxis es que el código se romperá si una declaración adicional que se añade sin también la adición de los soportes. En general, sin embargo, el código no se debe escribir para adaptarse a los cambios que puedan surgir.

6.2 Espacio en blanco

73. - Los operadores deben estar rodeados por un espacio. - Java palabras reservadas debe ser seguido por un espacio en blanco. - Las comas debe ser seguido por un espacio en blanco. - Dos puntos deben estar rodeados por espacios en blanco. - Los puntos y comas en las declaraciones debe ser seguido por un carácter de espacio. a = (b + c) * d / / NO: a = (b + c) * d while (true) {/ / NO: while (true) {... doSomething (a, b, c, d); / / NO: doSomething (a, b, c, d), y caso 100: / / NO: case 100: for (i = 0; i <10, i + +) {/ / NO: for (i = 0; i <10, i + +) {... Hace que los componentes individuales de los estados se destacan y mejora la legibilidad. Es difícil dar una lista completa del uso propuesto de espacios en blanco en el código Java. Los ejemplos anteriores no obstante, debe dar una idea general de las intenciones. 74. Nombres de método puede ser seguido por un espacio en blanco cuando es seguido por otro nombre. doSomething (currentFile); Hace que los nombres individuales se destacan. Mejora la legibilidad. Cuando no hay ningún nombre indica, el espacio puede ser omitido (doSomething ()) ya que no hay ninguna duda sobre el nombre en este caso.

Una alternativa a este enfoque es que requieren un espacio después del paréntesis de apertura. Los que se adhieren a esta norma general también dejar un espacio antes del paréntesis de cierre: doSomething (currentFile). Esto pone los nombres individuales se destacan como es la intención, pero el espacio antes del paréntesis de cierre es más bien artificial, y sin este espacio la declaración parece bastante asimétrica (doSomething (currentFile);). 75. Las unidades lógicas dentro de un bloque deben estar separados por una línea en blanco. / / Crear una nueva identidad Matrix4x4 matriz matriz = new Matrix4x4 (); / / ángulos precompute doble de eficiencia cosAngle = Math.cos (angle); sinAngle doble = Math.sin (ángulo) / / Especificar la matriz como una matriz de transformación de rotación . setElement (1, 1, cosAngle); matrix.setElement (1, 2, sinAngle); matrix.setElement (2, 1,-sinAngle); matrix.setElement (2, 2, cosAngle); / / Aplicar la transformación de rotación. multiplicar (matriz); Mejora la legibilidad mediante la introducción de un espacio en blanco entre las unidades lógicas. Cada bloque se introduce a menudo por un comentario tal como se indica en el ejemplo anterior. 76. Los métodos deben ser separados por tres líneas en blanco. Al hacer el espacio más grande que el espacio dentro de un método, los métodos se destacan dentro de la clase. 77. Variables en las declaraciones pueden ser alineados a la izquierda. Archivo archivo de texto; NPOINTS int, double x, y; Mejora la legibilidad. Las variables son más fáciles de encontrar desde los tipos de alineación. 78. Las declaraciones deberán estar alineados siempre que ello mejora la legibilidad.

if (a == escasa cuantía) compueSomething (); else if (a == mediumValue) computeSomethingElse (); else if (a == highValue) computeSomethingElseYet (); = valor (potencial oilDensity *) / constante1 + (profundidad * waterDensity) / constant2 + (zCoordinateValue gasDensity *) / constant3; minPosition = computeDistance (min, x, y, z); averagePosition = computeDistance (promedio, x, y, z); switch (fase) {PHASE_OIL caso: text = "Petróleo" ; break; PHASE_WATER caso: text = "Agua"; break; PHASE_GAS caso: text = "Gas"; break;} Hay un número de lugares en donde el código se puede espacio en blanco incluido para mejorar la legibilidad, incluso si esto viola las directrices comunes. Muchos de estos casos tienen que ver con la alineación del código. Directrices generales para la alineación código son difíciles de dar, pero los ejemplos anteriores deberían dar algunos consejos generales. En definitiva, cualquier construcción que mejora la legibilidad se debe permitir.

6,3 Comentarios

79. Tricky código no debe ser comentado pero reescrito [1] . En general, el uso de comentarios debe reducirse al mínimo, haciendo que el código de auto-documentado por opciones de nombre adecuados y una estructura lógica explícita. 80. Todos los comentarios deben ser escritos en Inglés. En un entorno internacional Inglés es el idioma preferido. 81. Comentarios Javadoc debería tener la siguiente forma: / *** Devuelve la ubicación lateral de la posición especificada. * Si la posición no está definida, se devuelve NaN. ** @ Param x Coordenada X de la posición. * @ Param y coordenada de posición. * @ Param Zona zona de posición. * @ Return ubicación lateral. * @ Throws IllegalArgumentException Si la zona es <= 0. * / Public double computeLocation (double x, double y, int zona) throws IllegalArgumentException {... } Una forma legible es importante porque este tipo de documentación se suele leer con mayor frecuencia dentro del código de lo que es el texto como procesado.

Tenga en cuenta en particular:

La apertura / ** en una línea separada * Posterior se alinea con la primera Espacio después de cada * Línea en blanco entre la descripción y la sección de parámetros. Alineación de las descripciones de los parámetros. Puntuacion detrás de la descripción de cada parámetro. No hay línea en blanco bewteen el bloque de documentación y el método / clase.

Javadoc de miembros de la clase pueden especificarse en una sola línea de la siguiente manera:

/ ** El número de conexiones a la base de datos * / nConnections_ int privado;

82. Debe haber un espacio después del identificador de comentario. / / Esto es un comentario no: / / Esto es un comentario / ** NO: / *** Este es un javadoc * Este es un javadoc * comentario * comentario * / * / Mejora la legibilidad, haciendo que el texto se destacan. 83. Utilice / / para todos los comentarios JavaDoc no, incluyendo comentarios de varias líneas. / / Añadir abarcan / / más de una línea. Dado que Java multinivel comentando no es compatible, usando / / Comentarios asegurarse de que siempre es posible inhabilitar secciones enteras de un archivo mediante / ** / con fines de depuración, etc 84. Los comentarios deben tener una sangría en relación con su posición en el código [1] . while (true) {/ / NO: while (true) {/ / Hacer algo / / Hacer algo algo (), algo ();}} Esto es para evitar que los comentarios de romper la estructura lógica del programa. 85. La declaración de variables colección anónima debe ser seguido por un comentario indicando el tipo común de los elementos de la colección. points_ Vector privado; / / de shapes_ Set Point privado; / / de forma Sin el comentario adicional que puede ser difícil de entender lo que la colección consisten en, y por lo tanto la forma de tratar los elementos de la colección. En los métodos que toman las variables de recogida como entrada, el tipo común de los elementos se debe dar en el comentario JavaDoc asociado.

Siempre que sea posible se debe, por supuesto calificar la colección con el tipo para hacer el comentario superfluo:

Vector privado <Point> points_; Set privado <forma> shapes_;

86. Todas las clases y funciones públicas públicos y protegidos dentro de las clases públicas deben documentarse utilizando la documentación de Java (javadoc) convenciones. Esto hace que sea fácil de mantener al día la documentación de códigos online.