ESTILO DE CODIFICACIN CONVENCIONES PARA LOS NOMBRES DE LOS ARCHIVOS Los archivos que contienen cdigo fuente en el lenguaje

de programacin Java deben tener la extensin .java, mientras que los archivos compilados de bytecode deben tener extensin .class. CONVENCIONES PARA LA ORGANIZACIN DE LOS ARCHIVOS Los archivos no deben tener ms de 2000 lneas, porque resulta farragoso trabajar con ellos. Cada archivo contiene una nica clase o interfaz pblica. Cuando haya clases o interfaces privadas asociadas con una clase pblica, se pueden poner en el mismo archivo que la clase pblica. La clase o interfaz pblica debe ser la primera en el archivo. El orden de los contenidos debe ser: comentarios iniciales, paquete y sentencias de importacin, declaracin de clase o interfaz. Dentro de una clase, se debe declarar primero las variables estticas, primero aquellas que sean pblicas, despus las marcadas como protected seguidas de las que no tengan ningn modificador y finalmente las privadas. Despus se debe declarar las variables de instancia, ordenadas por el modificador de acceso del mismo modo que se hace con las variables estticas. Entonces se declararn los constructores, y finalmente el resto de mtodos. Los archivos se organizarn en directorios, siguiendo la especificacin de paquetes de Sun de forma bsica, y especficamente siguiendo las siguientes directrices: El paquete bsico de la aplicacin debe tener el nombre com.guadaltel.tim Cada mdulo tendr un paquete propio a partir del paquete bsico. El cdigo comn todas las aplicaciones se situar en un paquete denominado comun, a partir del cual se pueden generar paquetes para organizar su contenido. La estructura de paquetes a partir de esta estructura bsica debe ser coherente, lgica y sencilla. Se permite aadir paquetes a partir de com.guadaltel.tim, pero no en niveles superiores. CONVENCIONES PARA LA ALINEACIN DEL CDIGO La unidad de sangrado del cdigo debe ser la del tabulador.

Las lneas no tendrn ms de 80 caracteres. Cuando una expresin no se pueda disponer en una nica lnea, se dividir siguiendo los siguientes principios: Dividir tras una coma. Dividir antes de un operador. Alinear la nueva lnea respecto a la expresin del mismo nivel de la lnea superior.

Las clases y los comentarios de documentacin no tienen sangrado, mientras que los miembros de las clases s deben estar sangrados. Se usar una nica lnea en blanco para separar mtodos, variables locales y el resto de sentencias de un mtodo, antes de un bloque o un comentario de una lnea y entre secciones lgicas de un mtodo para mejorar la legibilidad. Se debe usar un espacio en blanco despus de usar una palabra clave a la cual le siguen parntesis, despus de una coma en una lista de argumentos, entre todos los operadores binarios excepto . pero nunca entre operadores unarios, entre las expresiones de una sentencia for y cuando se fuerza el tipo mediante un cast. CONVENCIONES PARA LOS COMENTARIOS Los comentarios pueden ser de dos tipos, comentarios de implementacin y comentarios de documentacin. Los comentarios de implementacin son aquellos que aparecen entre /* */ o con //, mientras que los comentarios de documentacin son aquellos que aparecen entre /** /. Los comentarios de implementacin se utilizan para comentar el cdigo o para comentar una implementacin particular. Los comentarios de documentacin se usan para describir la especificacin del cdigo, desde una perspectiva independiente de la implementacin, y van dirigidos a desarrolladores que no tienen que tener el cdigo fuente a mano. Se deben realizar comentarios de documentacin de los mtodos pblicos y protected, y los paquetes, de la siguiente forma: Descripcin de la funcin del mtodo. Definicin de cada parmetro, funcional y dominio de valores. Definicin del valor de retorno, si lo hay. Definicin de las condiciones del lanzamiento de excepciones, si se pueden dar. Opcionalmente, se puede especificar un ejemplo si fuese necesario.

Los comentarios deben dar una descripcin del cdigo y dar informacin adicional que no se puede extraer del propio cdigo. Los comentarios deben contener informacin que sea relevante para leer y entender el programa.

Se puede documentar decisiones de diseo que no sean triviales u obvias, pero se debe evitar duplicar informacin que est presente (de forma clara) en el cdigo. Evitar comentarios sobre aspectos que pueden quedar obsoletos a medida que el cdigo evolucione. Los comentarios no deben inscribirse en cajas dibujadas con asteriscos u otros caracteres. Los comentarios nunca deben contener caracteres especiales. Los comentarios pueden tomar la forma de bloque, una sola lnea y al final de una lnea de sentencia. Cuando los comentarios aparezcan al final de una lnea de sentencia deben estar suficientemente separados de la sentencia, y si aparecen varios comentarios de este tipo en un mismo bloque de cdigo, deben alinearse de la misma forma. CONVENCIONES PARA LAS DECLARACIONES Se debe realizar una nica declaracin por lnea. No se debe mezclar tipos en una misma lnea. Se puede tabular la declaracin de las variables para alinear los nombres de las variables. Las variables locales se deben inicializar donde se hayan declarado. Slo se debe inicializar de otra forma si su valor inicial depende de un clculo que se deba realizar previamente. Las declaraciones se deben situar al inicio de un bloque de cdigo, excepto cuando se use un bucle for. Se debe evitar usar declaraciones locales que oculten declaraciones de nivel superior. No se debe dejar espacio entre el nombre de un mtodo y el parntesis que inicia la lista de parmetros. La llave que abre un bloque de cdigo debe aparecer al final de la lnea que declara la sentencia. La llave que cierra un bloque debe situarse en una lnea a parte, y se debe alinear con el inicio de la sentencia donde se sita la llave de apertura. Cuando en un bloque no haya sentencias, las llaves deben estar juntas en la misma lnea. Los mtodos se separan por una lnea en blanco. CONVENCIONES PARA LAS SENTENCIAS Cada lnea debe contener una nica sentencia. Las sentencias compuestas, situadas entre llaves, se deben sangrar un nivel ms sus sentencias que la sentencia en la que se encuentran incluidas. La llave de inicio del bloque se sita al final de la lnea donde se inicia la sentencia compuesta. Siempre se debe poner las llaves en cualquier bloque, aunque tenga una nica sentencia.

Las sentencias de retorno no tendrn parntesis a no ser que ello contribuya a su mejor compresin. Los bucles for y while que no tengan ninguna sentencia en su bloque no deben tener llaves, slo un punto y coma al final. Los casos de una sentencia switch que no deban incluir break debe comentarse para explicitarlo. CONVENCIONES PARA LOS NOMBRES El prefijo de un nombre de paquete debe escribirse siempre en letras ASCII minsculas, y debe coincidir con alguno de los nombres de dominio de ms alto nivel como com, edu, gov, mil, net, org o alguno de los cdigos de dos letras para los pases que establece el ISO Standard 3166, 1981. Los siguientes componentes del nombre de paquete dependern de las convenciones internas de cada organizacin. Los nombres de clases deben ser sustantivos, con la primera letra de cada palabra en mayscula y el resto en minscula. Los nombres de clases se deben mantener simples y descriptivos. Se debe usar palabras completas y evitarse acrnimos y abreviaciones, excepto cuando sean de uso ms extendido que las palabras completas. Esto mismo se aplica a las interfaces. Los mtodos deben ser verbos en minscula. Los nombres de variables no deben comenzar con guin bajo ni con el signo del dlar, aunque est permitido. Los nombres de las variables deben ser cortos y descriptivos. Los nombres de las variables deben recordar la funcin de stas. No se debe usar nombres de una nica letra, excepto para las variables temporales de contadores. Las variables que declaren constantes de clase deben estar en maysculas con las palabras separadas por guin bajo. Las constantes ANSI deben evitarse. PRCTICAS DE PROGRAMACIN No hacer que las variables sean pblicas a menos que sea necesario. No utilizar una instancia para acceder a variables y mtodos de clase. Las constantes numricas (literales) no se deben codificar directamente, excepto los valores -1, 0 y 1 en los bucles for. Evitar asignar varias variables con el mismo valor en una nica sentencia. No usar el operador de asignacin donde pueda confundirse con el operador de igualdad.

No usar asignaciones enlazadas para mejorar el rendimiento. Se recomienda usar parntesis de forma extensa para evitar problemas de precedencia. Si aparece una expresin binaria antes del interrogante en una operacin con el operador ternario, esta expresin se debe poner entre parntesis. Usar xxx para comentar un cdigo errneo pero que funciona, y FIXME para comentar un cdigo errneo y que no funciona. Se recomienda el uso de patrones de diseo cuando puedan ser de utilidad, aunque no es obligatorio su uso. Consutar los consejos de Sun aqu.