Reglas de programacin de Java

Versin 6.3, enero de 2011 Servicios Geotcnicos Software Copyright 1998 - 2011 Este documento est disponible en http://geosoft.no/development/javastyle.html

Tabla de Contenido
1 Introduccin 1.1 Estructura de las Recomendaciones 1.2 Recomendaciones Importancia 1.3 Comprobacin automtica de Estilo 2 Recomendaciones generales 3 Convenciones de nomenclatura 3.1 Convenciones generales de nomenclatura 3.2 Convenciones de nombres especficos 4 Archivos 5 Estados 5,1 de paquetes y sentencias de importacin 5.2 Clases e Interfaces 5.3 Modalidades 5.4 Tipos 5.5 Variables 5,6 Loops 5.7 Condicionales 5,8 Varios 6 Presentacin y Comentarios 6.1 Diseo 6.2 El espacio en blanco 6,3 Comentarios 7 Referencias

1 Introduccin
Este documento enumera las recomendaciones de codificacin Java comunes en el desarrollo de la comunidad Java. Las recomendaciones se basan en las normas establecidas recogidos de un nmero de fuentes, la experiencia individual, requisitos / necesidades locales, as como sugerencias dadas en [1] , [2] , [3] , [4] y [5] . Hay varias razones para la introduccin de una nueva directriz y no slo en referencia a los anteriores. La razn principal es que estas guas son demasiado generales en su alcance y que las reglas ms especficas (especialmente las normas de denominacin) deben ser establecidos. Asimismo, la presente gua tiene una forma anotada que hace que sea ms fcil de usar durante las revisiones de cdigo del proyecto que la mayora de las directrices existentes. Adems, las recomendaciones de programacin en general, tienden a mezclar los problemas de estilo con problemas de lenguaje tcnico de una manera un tanto confusa. El presente documento no contiene todas las recomendaciones tcnicas de Java en absoluto, sino que se centra principalmente en el estilo de programacin. Mientras que un entorno de desarrollo dado (IDE), puede mejorar la legibilidad del cdigo de acceso por la visibilidad, codificacin de color, el formato automtico y as sucesivamente, el programador no debe confiar en tales caractersticas. El cdigo fuente se debe considerar siempre ms 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 estn agrupadas por tema y cada recomendacin se numera para que sea ms fcil referirse a durante las revisiones. Disposicin para las recomendaciones es el siguiente: n. Gua breve descripcin Ejemplo si es aplicable La motivacin, la formacin y la informacin adicional. La seccin de la motivacin es importante. Los estndares de codificacin y pautas tienden a empezar "guerras de religin", y es importante sealar los antecedentes de la recomendacin.

Recomendacin 1.2 Importancia

En las secciones de orientacin de los trminos debe, puede y debe tener un significado especial. Un requisito imprescindible debe ser seguido, a deben es una recomendacin fuerte, y una lata es una pauta general.

1.3 Comprobacin automtica de Estilo

Muchas herramientas ofrecen la comprobacin automtica de cdigo del estilo. Uno de el ms popular y rica caracterstica es Checkstyle por Oliver Burn. Checkstyle se configura a travs de un archivo XML de reglas de estilo que se aplica al cdigo fuente. Es muy til si se integra en el proceso de construccin o el entorno de desarrollo. Hay plugins Checkstyle para todos los IDEs ms populares disponibles. Para utilizar Checkstyle con las reglas de estilo Geosoft a continuacin, utilizar el archivo de configuracin: geosoft_checks.xml .

2 Recomendaciones generales
1. Cualquier violacin a la gua si se permite que mejora la legibilidad. El principal objetivo de la recomendacin es para facilitar la lectura y por lo tanto la comprensin y la facilidad de mantenimiento y la calidad general del cdigo. Es imposible cubrir todos los casos especficos en una gua 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 minsculas. mypackage, com.company.application.ui Paquete de convencin de nomenclatura utilizada por Sun para los paquetes bsicos de Java. El nombre del paquete inicial que representa el nombre de dominio debe estar en minsculas. 3. Nombres que representan los tipos deben ser sustantivos y escrito en maysculas y minsculas comenzando con mayscula. Line, AudioSystem La prctica comn en la comunidad de desarrollo de Java y tambin la convencin de nomenclatura tipo utilizado por Sun para los paquetes bsicos de Java. 4. Los nombres de variables deben estar en maysculas y minsculas comenzando con minscula. lnea, AudioSystem La prctica comn en la comunidad de desarrollo de Java y tambin la convencin de nombres para las variables usadas por Sun para los paquetes bsicos de Java. Hace que las variables fciles de distinguir de los tipos, y resuelve eficazmente posible colisin de nombres como en la lnea lnea de declaracin; 5. Nombres que representan constantes (variables final) debe estar en maysculas utilizando subrayado para separar palabras. MAX_ITERATIONS, Color_Red

La prctica comn en la comunidad de desarrollo de Java y tambin la convencin de nomenclatura utilizada por Sun para los paquetes bsicos de Java. En general, el uso de constantes debe reducirse al mnimo. En muchos casos la aplicacin del valor como un mtodo es una mejor eleccin:
getMaxIterations int () / / No: MAX_ITERATIONS = 25 { volver 25; }

Esta forma es ms fcil de leer, y garantiza una interfaz uniforme a los valores de la clase. 6. Nombres que representan los mtodos deben ser verbos y escrito en maysculas y minsculas comenzando con minscula. getName (), computeTotalWidth () La prctica comn en la comunidad de desarrollo de Java y tambin la convencin de nomenclatura utilizada por Sun para los paquetes bsicos de Java. Esto es idntico a los nombres de variables, pero los mtodos en Java son ya distinguibles de las variables por su forma especfica. 7. Abreviaturas y siglas no deben estar en maysculas cuando se usa como nombre. exportHtmlSource (); / / NO: exportHTMLSource (); openDvdPlayer (); / / NO: openDVDPlayer (); Uso maysculas 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 acrnimo no destaca como debera. 8. Las variables privadas de la clase debera haber subrayado sufijo. class Person {private String name_; ... } Aparte de su nombre y su tipo, el alcance de una variable es su caracterstica ms importante. Indicando mbito de la clase mediante el uso de relieve hace que sea fcil distinguir las variables de clase a partir de variables scratch locales. Esto es importante porque las variables de clase se considera que tienen mayor significacin de variables del mtodo, y debe tratarse con especial cuidado por el programador. Un efecto secundario de la convencin de nomenclatura subrayado es que muy bien se resuelve el problema de encontrar razonables nombres de variable para mtodos de establecimiento:
vaco setName (String nombre) { name_ = nombre; }

Una cuestin es si el guin bajo se debe agregar como prefijo o como sufijo. Ambas prcticas son de uso general, pero este ltimo es recomendable porque parecen conservar

mejor la lectura del nombre. Cabe sealar que la identificacin alcance en las variables han sido un tema controvertido desde hace bastante tiempo. Parece, sin embargo, que esta prctica ahora est ganando adeptos y que cada vez es ms y ms comn como una convencin en la comunidad de desarrollo profesional. 9. Las variables genricas deben tener el mismo nombre que su tipo. vaco setTopic (tema Tema) / / NO: setTopic vaco (valor Topic) / / NO: setTopic vaco / / NO (Tema atpica): 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 nmero de trminos y nombres utilizados. Tambin hace fcil deducir el tipo dado un nombre de variable nica. Si por alguna razn esta convencin no parece encajar es una fuerte indicacin de que el nombre del tipo es mal elegido. No genricas variables tienen un papel importante. Estas variables pueden a menudo ser identificado mediante la combinacin de papel y escriba:
Punto startingPoint, CenterPoint; Nombre loginName;

10. Todos los nombres deben ser escritos en Ingls. Ingls es el idioma preferido para el desarrollo internacional. 11. Las variables con un mbito de aplicacin general deben tener nombres largos, las variables con un alcance pequeo puede tener nombres cortos [1] . Las variables virtual utilizada para el almacenamiento temporal o ndices son ms cortos. Un programador de la lectura de variables tales deben ser capaces de asumir que su valor no se utiliza fuera de unas pocas lneas de cdigo. Variables comunes reutilizables para enteros i son, j, k, m, n y para caracteres c y d. 12. El nombre del objeto es implcito, y se debe evitar en un nombre de mtodo. line.getLength (); / / NO: line.getLineLength (); Este ltimo podra parecer natural en la declaracin de la clase, pero resulta superfluo en uso, como se muestra en el ejemplo.

3.2 Convenciones de nomenclatura especficas

13. Los trminos 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 prctica comn en la comunidad de Java y la convencin utilizada por Sun para los paquetes bsicos de Java. 14. Es prefijo debe ser utilizado para las variables booleanas y mtodos. isSet, isVisible, isFound isFinished, isOpen Esta es la convencin de nomenclatura para mtodos y variables booleanas utilizadas por Sun para los paquetes bsicos de Java.

Con el prefijo es resuelve un problema comn de elegir mal los nombres lgicos como el estatus o la bandera. IsStatus isFlag o simplemente no encaja, y el programador se ve obligado a escoger los nombres ms significativos. Mtodos de establecimiento de las variables booleanas debe haber configurado como prefijo en:
vaco 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 trmino compute puede utilizarse en mtodos donde algo se computado. valueSet.computeAverage (); matrix.computeInverse () Dar al lector la idea de inmediato que se trata de una operacin que consume tiempo potencial, y si se utiliza repetidamente, se podra considerar el almacenamiento en cach el resultado. El uso constante del trmino mejora la legibilidad. 16. El trmino encontrar se puede utilizar en mtodos 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 mtodo con un mnimo de clculos involucrados. El uso constante del trmino mejora la legibilidad. 17. La inicializacin trmino puede ser usado donde un objeto o un concepto se ha establecido. printer.initializeFontSet (); La inicializacin americano se prefiere en la inicializacin de Ingls. 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 coleccin 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 nmero de objetos. NPOINTS, nlines La notacin se toma de las matemticas en el que es una convencin establecida para indicar un nmero de objetos. Tenga en cuenta que el uso dom prefijo num en los paquetes bsicos de Java para dichas

variables. Esto probablemente se entiende como una abreviatura del nmero de, pero a medida que se parece ms a nmero tiene el nombre de variable extrao y engaoso. Si "nmero de" es la frase preferida, prefijo Nmerode se puede utilizar en lugar de n. Prefijo de nmero no debe ser utilizado. 21. No sufijo debe ser utilizado para variables que representan un nmero de entidad. Tableo, employeeNo La notacin es tomado de las matemticas, donde es una convencin establecida para indicar un nmero 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 notacin es tomado de las matemticas, donde es una convencin 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, aadir / 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 simetra. 24. Las abreviaturas en los nombres debe ser evitado. computeAverage (); / / NO: compAvg (); ActionEvent evento, / / NO: e ActionEvent; catch (Exception Excepcin) {/ / NO: catch (Exception e) { Hay dos tipos de palabras a considerar. En primer lugar estn 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 excepcin init en lugar de inicializar pt en vez de punto

etctera Entonces hay frases especficas de dominio que son naturalmente ms conocidos por su acrnimo 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

etctera 25. Negada nombres de las variables booleanas deben ser evitados. bool isError; / / NO: isNoError bool isFound / / NO: isNotFound

El problema surge cuando el operador lgico no se utiliza y doble negacin se presenta. No es inmediatamente evidente qu! IsNotError significa. 26. Constantes asociados (variables final) debe estar precedido por un nombre de tipo comn. 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 excepcin debe ser con el sufijo Exception. AccessException clase extends Exception {:} Clases de excepcin no son realmente parte del diseo principal del programa, y nombrarlos como este hace destacar con respecto a las otras clases. Esta norma es seguida por Sun en la biblioteca bsica de Java. 28. Las implementaciones por defecto de la interfaz puede ir precedido por defecto. DefaultTableCellRenderer clase implementa TableCellRenderer {:} No es poco comn para crear una implementacin de la clase simplista de una interfaz que proporciona el comportamiento por defecto para los mtodos de interfaz. La convencin 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 travs del mtodo 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 prctica comn en la comunidad de Java aunque no siempre seguida de Sol en el JDK. La disposicin anterior es el patrn preferido. 30. Las clases que se crean instancias en nombre de otros (fbricas) puede hacerlo a travs del mtodo nuevo [ClassName] clase PointFactory {Newpoint pblica Point (...) {... }} Indica que la instancia se crea de nuevo en el mtodo de la fbrica y que la construccin es un reemplazo controlado de nuevo Punto (). 31. Las funciones (mtodos devuelven un objeto) debe ser el nombre de lo que regresar y procedimientos (mtodos void) despus de lo que hacen. Aumentar la legibilidad. Hace que sea ms 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 ms fcil de mantener el cdigo limpio de efectos secundarios.

4 Archivos

32. Archivos fuente de Java debe tener la extensin. 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 dimensin comn 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 lnea se evitan cuando se pasa de un archivo entre los programadores. 35. Los caracteres especiales como pausa TAB y la pgina debe ser evitado. Estos personajes estn 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 carcter incompleto de lneas de divisin debe hacerse evidente [1] . totalSum = a + b + c + d + e; mtodo (param1, param2, param3); setText ("Larga cola dividir" + "en dos partes."); for (int Tableo = 0; Tableo <nTables; Tableo + = tableStep) {... } Las lneas de divisin se produce cuando una instruccin exceder el lmite de columna 80 dado anteriormente. Es difcil dar reglas rgidas para el nmero de lneas debe ser dividido, pero los ejemplos anteriores deberan dar una pista general. En general:

Romper despus de una coma. Descanso despus de un operador. Alinear la nueva lnea con el principio de la expresin en la lnea anterior.

5 Estados
5,1 de paquetes y sentencias de importacin
37. La declaracin de paquetes debe ser la primera instruccin del expediente. Todos los archivos deben pertenecer a un paquete especfico. La ubicacin declaracin 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 tcnicas de programacin orientada a objetos del lenguaje. 38. Las declaraciones de importacin debe seguir la instruccin package. Declaraciones de importacin se clasifican con los primeros paquetes ms fundamentales, y se agrupan en paquetes asociados entre s y una lnea en blanco entre los

grupos. java.io.IOException importacin; java.net.URL importacin; java.rmi.RmiServer importacin; java.rmi.server.Server importacin; javax.swing.JPanel importacin; javax.swing.event.ActionEvent importacin, importacin org.linux . apache.server.SoapServer; La ubicacin declaracin de importacin impuesto por el lenguaje Java. La clasificacin hace que sea sencillo para navegar por la lista cuando hay muchas importaciones, y hace que sea fcil determinar los dependiencies del paquete actual La agrupacin reducir la complejidad por el colapso de la informacin relacionada en una unidad comn. 39. Clases importadas siempre debe aparecer de forma explcita. java.util.List importacin; / / NO: java.util import *; java.util.ArrayList importacin, importacin java.util.HashSet;. Importacin de clases explcitamente da un valor excelente documentacin para la clase a la mano y hace la clase ms fcil de comprender y mantener. Herramientas apropiadas deben ser utilizados con el fin de mantener siempre la lista de importacin mnimo y hasta la fecha.

5.2 Clases e Interfaces

40. Declaraciones de clases e interfaces deben organizarse de la siguiente manera: 1. Clase / Interface documentacin. 2. clase o declaracin de interfaz. 3. De clase (estticos) variables en el orden pblico, proteger, paquete (sin modificador de acceso), privado. 4. Las variables de instancia en el orden pblico, proteger, paquete (sin modificador de acceso) y privada. 5. Constructores. 6. Los mtodos (sin ningn orden especfico). Reducir la complejidad por lo que la ubicacin de cada elemento de la clase predecible.

5.3 Modalidades
41. Modificadores mtodo debe ser dado en el orden siguiente: <access> abstracto esttico sincronizado nativo ltimo <unusual> El modificador <access> (si est presente) debe ser el primer modificador. plaza pblica esttica doble (double a); / / NO: static public double cuadrado (double a); <access> es uno de los pblicos, protegidos o privados mientras <unusual> incluye voltiles y transitorias. La leccin ms importante aqu es mantener el modificador de acceso como el primer modificador. De los posibles modificadores, esto es, con mucho, el ms importante, y debe destacarse en la declaracin de mtodo. Para los otros modificadores, el orden es menos importante, pero tiene sentido tener una convencin fija.

5.4 Tipos
42. Conversiones de tipos debe realizarse siempre de forma explcita. Nunca confe en la conversin de tipos implcita. floatValue = (int) intValue; / / NO: floatValue = intValue; Por ello, el programador indica que es consciente de los diferentes tipos involucrados y que la combinacin 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 funcin 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 ms pequeo posible. Esto asegura que las variables son vlidas en cualquier momento. A veces no es posible inicializar una variable a un valor vlido 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 estn representados de forma exclusiva. Reducir la probabilidad de error por efectos secundarios. 46. Las variables de clase nunca debe ser declarado pblico. El concepto de ocultacin de informacin y encapsulacin Java es violado por las variables pblicas. Usar variables y funciones privadas de acceso en su lugar. Una excepcin 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 pblica [2] . 47. Las matrices deben declararse con sus parntesis junto al tipo. double [] vrtice; / / NO: doble vrtice [], int [] Count / / NO: int cuenta; [] public static void main (String [argumentos]) public double computeVertex [] () La razn de es doble. En primer lugar, la matriz-ness es una funcin de la clase, no de la variable. En segundo lugar, al devolver una matriz de un mtodo, no es posible tener los soportes con excepcin 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 pequeo, es ms fcil controlar los efectos y efectos secundarios de la variable.

5,6 Loops
49. Slo los estados de control de bucle debe ser incluido en la construccin 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 distincin 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. Adems, el do-while no son necesarios. Cualquier do-while puede ser reescrito en un bucle while o un bucle for. La reduccin del nmero de construcciones utilizadas mejorar readbility. 52. El uso de romper y continuar en bucles debe ser evitado. Estas declaraciones slo se debe utilizar si se demuestra que den una mayor facilidad de lectura que sus homlogos 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 asignacin de variables booleanas a las expresiones, el programa obtiene documentacin automtica. La construccin ser ms fcil de leer, depurar y mantener. 54. El caso nominal debe ser puesto en la si-parte y la excepcin 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 ejecucin. Esto es importante tanto para la legibilidad y el rendimiento. 55. El condicional se debe poner en una lnea separada. if (isDone) / / NO: if (isDone) doCleanup (); doCleanup (); Esto es para propsitos de depuracin. Al escribir en una sola lnea, 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 difcil de leer. Esto es especialmente cierto para los nuevos programadores de Java.

5,8 Varios
57. El uso de nmeros mgicos en el cdigo debe ser evitado. Nmeros 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 nmero no tiene un significado evidente por s misma, la legibilidad se mejora mediante la introduccin de una constante denominada en su lugar. 58. Constantes de punto flotante siempre debe ser escrito con punto decimal y un decimal como mnimo. 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 nmeros enteros y de punto flotante. Matemticamente los dos conceptos completamente diferentes modelos y no compatibles. Tambin, como en el ltimo ejemplo anterior, se destaca el tipo de la variable asignada (suma) en un punto en el cdigo donde esto podra no ser evidente. 59. Constantes de punto flotante siempre se debe escribir con un dgito antes del punto decimal. doble total = 0,5; / / NO: total doble = .5; El nmero y el sistema de expresin en Java est tomado de las matemticas y uno debe adherirse a las convenciones matemticas de sintaxis siempre que sea posible. Tambin, 0,5 es mucho ms fcil de leer que .5; No hay manera de que se puede mezclar con el entero 5. 60. Las variables estticas o mtodos siempre deben ser referidos a travs del nombre de la clase y no a travs de una variable de instancia. Thread.sleep (1000), / / NO: Thread.Sleep (1000); Esta destacar que las referencias de elementos es esttico e independiente de cualquier instancia particular. Por la misma razn el nombre de clase debe incluirse tambin cuando una variable o mtodo se accede desde dentro de la misma clase.

6 Presentacin y Comentarios
6.1 Diseo
61. Hendidura bsica debe ser 2. for (i = 0; i <nElements, i + +) a [i] = 0; La sangra se utiliza para enfatizar la estructura lgica del cdigo. Sangra de 1 es demasiado pequea para lograr esto. La sangra de ms de 4 hace que el cdigo profundamente anidado difcil de leer y aumentar la posibilidad de que las lneas se deben dividir. La eleccin entre indentacin de 2, 3 y 4; 2 y 4 son los ms comunes, y 2 a disminuir la probabilidad de lneas de cdigo de divisin. Tenga en cuenta que la recomendacin de Sun en este punto es 4. 62. Diseo de bloque debe ser como se ilustra en el ejemplo 1 a continuacin (recomendado) o ejemplo 2, y no debe ser como se muestra en el ejemplo 3. Bloques de clase, interfaz y mtodo debe utilizar el diseo de bloque del ejemplo 2. while (hecho!) while (hecho!) while (hecho!) {doSomething {doSomething (); {doSomething (); (); moreToDo hecho = ();} moreToDo hecho = ();} moreToDo hecho = ();}

Ejemplo 3 introducir un nivel de indentacin adicional que no hace hincapi en la estructura lgica del cdigo tan claramente como ejemplo 1 y 2. 63. Las declaraciones de clase y la interfaz debe tener la siguiente forma: Rectngulo clase ampla Shape implementa Cloneable, Serializable {... } Esto se deduce de la regla general de bloques anteriormente. Ntese que es comn en la comunidad de desarrolladores Java para que el soporte de abertura en el extremo de la lnea de la clase de palabras clave. Esto no es recomendable. 64. Definiciones de mtodo debe tener la siguiente forma: algunMetodo public void () throws SomeException {... } Vase el comentario sobre las declaraciones de clases anteriores. 65. La clase if-else de los estados deben tener la siguiente forma: if (condicin) {sentencias;} if (condicin) {sentencias;} else {sentencias;} if (condicin) {sentencias;} else if (condicin) {sentencias;} else {sentencias;} Esto se deriva en parte de la regla general de bloques anteriormente. Sin embargo, se podra examinar si una clusula else debe estar en la misma lnea que el corchete de cierre de la anterior clusula if o else:
if (condicin) { declaraciones; } Else { declaraciones; }

Esto es equivalente a la recomendacin dom El enfoque elegido se considera mejor en la forma en que cada parte de la instruccin if-else est escrito en lneas separadas del archivo. Esto debera hacer que sea ms fcil manipular el estado, por ejemplo cuando se mueve alrededor de clusulas else. 66. La declaracin de debe tener la forma siguiente: for (inicializacin; condicin; actualizacin) {sentencias;} Esto se deduce de la regla general de bloques anteriormente. 67. Un vaco de declaracin debe tener la siguiente forma: for (inicializacin; condicin; actualizacin); Este nfasis en el hecho de que la declaracin de est vaco y que hace que sea obvio para el lector que esto es intencional. 68. La sentencia while debera tener la siguiente forma: while (condicin) {sentencias;} Esto se deduce de la regla general de bloques anteriormente. 69. La sentencia do-while debera tener la siguiente forma: do {sentencias;} while (condicin); Esto se deduce de la regla general de bloques anteriormente. 70. La sentencia switch debera 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 recomendacin sol tanto en la sangra y el espaciado. En particular, cada palabra clave caso se sangra con respecto a la declaracin del interruptor como un todo. Esto hace que la sentencia switch entero se destacan. Tenga en cuenta tambin el espacio extra antes del: el carcter. El comentario explcito Fallthrough deben

incluirse cada vez que hay una sentencia case sin una sentencia break. Saliendo de la rotura de la salida es un error comn, y debe quedar claro que es intencional cuando no est all. 71. Una sentencia try-catch debera tener la siguiente forma: try {sentencias;} catch (Exception Excepcin) {sentencias;} try {sentencias;} catch (Exception Excepcin) {sentencias;} finally {sentencias;} Esto se deriva en parte de la regla general de bloques anteriormente. Esta forma difiere de la recomendacin dom de la misma manera como la instruccin if-else se ha descrito anteriormente. 72. Sola sentencia if-else, for o while declaraciones se puede escribir sin parntesis. if (condicin) instruccin; while (condicin) instruccin; for (inicializacin; condicin; update) declaracin; Es una recomendacin comn (Sun Java recomendacin incluido) que los soportes siempre se debe utilizar en todos estos casos. Sin embargo, los soportes son, en general, una construccin del lenguaje que los grupos de varias declaraciones. Los parntesis son por definicin superfluo en una sola sentencia. Un argumento comn en contra de esta sintaxis es que el cdigo se romper si una declaracin adicional que se aade sin tambin la adicin de los soportes. En general, sin embargo, el cdigo 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 carcter 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 difcil dar una lista completa del uso propuesto de espacios en blanco en el cdigo Java. Los ejemplos anteriores no obstante, debe dar una idea general de las intenciones. 74. Nombres de mtodo 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 ningn 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 despus del parntesis de apertura. Los que se adhieren a esta norma general tambin dejar un espacio antes del parntesis de cierre: doSomething (currentFile). Esto pone los nombres individuales se destacan como es la intencin, pero el espacio antes del parntesis de cierre es ms bien

artificial, y sin este espacio la declaracin parece bastante asimtrica (doSomething

(currentFile);).

75. Las unidades lgicas dentro de un bloque deben estar separados por una lnea 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 transformacin de rotacin . setElement (1, 1, cosAngle); matrix.setElement (1, 2, sinAngle); matrix.setElement (2, 1,sinAngle); matrix.setElement (2, 2, cosAngle); / / Aplicar la transformacin de rotacin. multiplicar (matriz); Mejora la legibilidad mediante la introduccin de un espacio en blanco entre las unidades lgicas. Cada bloque se introduce a menudo por un comentario tal como se indica en el ejemplo anterior. 76. Los mtodos deben ser separados por tres lneas en blanco. Al hacer el espacio ms grande que el espacio dentro de un mtodo, los mtodos 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 ms fciles de encontrar desde los tipos de alineacin. 78. Las declaraciones debern estar alineados siempre que ello mejora la legibilidad. if (a == escasa cuanta) 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 = "Petrleo" ; break; PHASE_WATER caso: text = "Agua"; break; PHASE_GAS caso: text = "Gas"; break;} Hay un nmero de lugares en donde el cdigo 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 alineacin del cdigo. Directrices generales para la alineacin cdigo son difciles de dar, pero los ejemplos anteriores deberan dar algunos consejos generales. En definitiva, cualquier construccin que mejora la legibilidad se debe permitir.

6,3 Comentarios
79. Tricky cdigo no debe ser comentado pero reescrito [1] . En general, el uso de comentarios debe reducirse al mnimo, haciendo que el cdigo de auto-documentado por opciones de nombre adecuados y una estructura lgica explcita. 80. Todos los comentarios deben ser escritos en Ingls. En un entorno internacional Ingls es el idioma preferido. 81. Comentarios Javadoc debera tener la siguiente forma: / *** Devuelve la ubicacin lateral de la posicin especificada. * Si la posicin no est definida, se devuelve NaN. ** @ Param x Coordenada X de la posicin. * @ Param y coordenada de posicin. * @ Param Zona zona de posicin. * @ Return ubicacin 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 documentacin se suele leer con mayor frecuencia dentro del cdigo de lo que es el texto como procesado. Tenga en cuenta en particular:

La apertura / ** en una lnea separada * Posterior se alinea con la primera Espacio despus de cada * Lnea en blanco entre la descripcin y la seccin de parmetros. Alineacin de las descripciones de los parmetros. Puntuacion detrs de la descripcin de cada parmetro. No hay lnea en blanco bewteen el bloque de documentacin y el mtodo / clase.

Javadoc de miembros de la clase pueden especificarse en una sola lnea de la siguiente manera:
/ ** El nmero de conexiones a la base de datos * / nConnections_ int privado;

82. Debe haber un espacio despus 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 lneas. / / Aadir abarcan / / ms de una lnea. 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 depuracin, etc 84. Los comentarios deben tener una sangra en relacin con su posicin en el cdigo [1] . while (true) {/ / NO: while (true) {/ / Hacer algo / / Hacer algo algo (), algo ();}} Esto es para evitar que los comentarios de romper la estructura lgica del programa. 85. La declaracin de variables coleccin annima debe ser seguido por un comentario indicando el tipo comn de los elementos de la coleccin. points_ Vector privado; / / de shapes_ Set Point privado; / / de forma Sin el comentario adicional que puede ser difcil de entender lo que la coleccin consisten en, y por lo tanto la forma de tratar los elementos de la coleccin. En los mtodos que toman las variables de recogida como entrada, el tipo comn de los elementos se debe dar en el comentario JavaDoc asociado. Siempre que sea posible se debe, por supuesto calificar la coleccin con el tipo para hacer el comentario superfluo:
Vector privado <Point> points_; Set privado <forma> shapes_;

86. Todas las clases y funciones pblicas pblicos y protegidos dentro de las clases pblicas deben documentarse utilizando la documentacin de Java (javadoc) convenciones. Esto hace que sea fcil de mantener al da la documentacin de cdigos online.