PROGRAMACIÓN

MOVIL II

ALBERTO LEONEL VIDARTE RODRIGUEZ

19100306 7°B1

Tarea: Java Conventions

Mtro. BECERRA DELGADO SERGIO

FECHA: 21/03/23

CENTRO DE ENSEÑANZA TECNICA INDUSTRIAL a19100306@ceti.mx

 Nombres de ficheros
Extensiones de los ficheros
El software Java usa las siguientes extensiones para los ficheros:

Tipo de fichero Extensión

Fuente Java .java

Bytecode de Java .class

Nombres de ficheros comunes

Los nombres de ficheros más utilizados incluyen:

Nombre de fichero Uso

GNUmakefile El nombre preferido para ficheros "make". Usamos gnumake para

construir nuestro software.

El nombre preferido para el fichero que resume los contenidos de un

README
directorio particular.

Organización de los ficheros

Un fichero consiste de secciones que deben estar separadas por líneas en
blanco ycomentarios opcionales que identifican cada sección.
Los ficheros de más de 2000 líneas son incómodos y deben ser evitados.

Ficheros fuente Java

Cada fichero fuente Java contiene una única clase o interfaz pública. Cuando algunas
clases o interfaces privadas estan asociadas a una clase pública, pueden ponerse en el
mismo fichero que la clase pública. La clase o interfaz pública debe ser la primera clase o
interfaz del fichero.
Los ficheros fuentes Java tienen la siguiente ordenación:
 • Comentarios de comienzo

• Sentencias package e import

• Declaraciones de clases e interfaces

Comentarios de comienzo

Todos los ficheros fuente deben comenzar con un comentario en el que se lista el nombre
de la clase, información de la versión, fecha, y copyright:
/*
* Nombre de la clase
*
* Informacion de la version
*
* Fecha
*
* Copyright
*/
Sentencias package e import

La primera línea no-comentario de los ficheros fuente Java es la sentencia package.

Despuésde esta, pueden seguir varias sentencias import. Por ejemplo:
package java.awt;

import java.awt.peer.CanvasPeer;
Declaraciones de clases e interfaces
La siguiente tabla describe las partes de la declaración de una clase o interface, en el
orden en que deberian aparecer

Partes de la declaración de
Notas
una clase o interface

Comentario de documentación
1 de la clase o interface
(/**...*/)

2 Sentencia class o interface

Comentario de Este comentario debe contener cualquier información

implementación de la clase o aplicable a toda la clase o interface que no era apropiada
3
interface si fuera necesario para estar en los comentarios de documentación de la clase
(/*...*/) o interface.
 Primero las variables de clase public, después las
4 Variables de clase (static) protected, después las de nivel de paquete (sin
modificador de acceso) , y despúes las private.

Primero las public, después las protected, después las de

5 Variables de instancia nivel de paquete (sin modificador de acceso), y después las
private.

6 Constructores

Estos métodos se deben agrupar por funcionalidad más que

por visión o accesibilidad. Por ejemplo, un método de clase
7 Métodos
privado puede estar entre dos métodos públicos de instancia.
El objetivo es hacer el código más legible y comprensible.

Indentación
Se deben emplear cuatro espacios como unidad de indentación. La construcción exacta
de la indentación (espacios en blanco contra tabuladores) no se especifica. Los
tabuladores deben ser exactamente cada 8 espacios (no 4).

Longitud de la línea
Evitar las líneas de más de 80 caracteres, ya que no son manejadas bien por
muchasterminales y herramientas.

Rompiendo líneas
Cuando una expresión no entre en una línea, romperla de acuerdo con estos principios:

• Romper después de una coma.

• Romper antes de un operador.

• Preferir roturas de alto nivel (más a la derecha que el "padre") que de bajo nivel
(más a la izquierda que el "padre").

• Alinear la nueva linea con el comienzo de la expresion al mismo nivel de la linea

anterior.

• Si las reglas anteriores llevan a código confuso o a código que se aglutina en

el margen derecho, indentar justo 8 espacios en su lugar.
 Comentarios
Los programas Java pueden tener dos tipos de comentarios: comentarios de
implementación ycomentarios de documentación. Los comentarios de implementación son
aquellos que también se encuentran en C++, delimitados por /*...*/, y //. Los comentarios
de documentación (conocidos como "doc comments") existen sólo en Java, y se limitan
por
/**...*/. Los comentarios de documentación se pueden exportar a ficheros HTML con la
herramienta javadoc.

Los comentarios de implementación son para comentar nuestro código o para

comentarios acerca de una implementación particular. Los comentarios de
documentación son para describir la especificación del código, libre de una perspectiva
de implementación, y para ser leídos por desarrolladores que pueden no tener el código
fuente a mano.

Se deben usar los comentarios para dar descripciones de código y facilitar información
adicional que no es legible en el código mismo. Los comentarios deben contener sólo
información que es relevante para la lectura y entendimiento del programa. Por ejemplo,
información sobre como se construye el paquete correspondiente o en que directorio
reside no debe ser incluida como comentario.

Son apropiadas las discusiones sobre decisiones de diseño no triviales o no obvias, pero
evitarduplicar información que esta presente (de forma clara) en el código ya que es fácil
que los comentarios redundantes se queden desfasados. En general, evitar cualquier
comentario que pueda quedar desfasado a medida que el código evoluciona.

Formatos de los comentarios de implementación

Los programas pueden tener cuatro estilos de comentarios de implementación: de
bloque, de una línea, de remolque, y de fin de línea

Comentarios de bloque

Los comentarios de bloque se usan para dar descripciones de ficheros, métodos,

estructuras de datos y algoritmos. Los comentarios de bloque se podrán usar al comienzo
de cada fichero o antes de cada método. También se pueden usar en otro lugares, tales
como el interior de los métodos. Los comentarios de bloque en el interior de una función o
método deben ser indentados al mismo nivel que el código que describen.

Un comentario de bloque debe ir precedido por una línea en blanco que lo separe del
resto del código.
/*
* Aqui hay un comentario de bloque.
*/
 Los comentarios de bloque pueden comenzar con /*-, que es reconocido por indent(1)
como el comienzo de un comentario de bloque que no debe ser reformateado.

Pueden aparecer comentarios cortos de una única línea al nivel del código que siguen. Si un
comentario no se puede escribir en una línea, debe seguir el formato de los comentarios de
bloque. Un comentario de una sóla línea debe ir precedido de una línea enblanco. Aqui un
ejemplo de comentario de una sola línea en código Java:
if (condicion) {

/* Código de la condicion. */
...
}
Comentarios de remolque

Pueden aparecer comentarios muy pequeños en la misma línea que describen, pero deben
sermovidos lo suficientemente lejos para separarlos de las sentencias. Si más de un
comentario corto aparecen en el mismo trozo de código, deben ser indentados con la misma
profundidad.

Aquí un ejemplo de comentario de remolque:

if (a == 2) {
return TRUE; /* caso especial */
} else {
return isPrime(a); /* caso gerenal */
}
Comentarios de fin de linea

El delimitador de comentario // puede convertir en comentario una línea completa o una

parte de una linea. No debe ser usado para hacer comentarios de varias líneas
consecutivas; sin embargo, puede usarse en líneas consecutivas para comentar
secciones de código
if (foo > 1) {

// Hacer algo.
...
}
else {
return false; //
//if (bar > 1) {
//
// // Hacer algo.
// ...
//}
//else {
// return false;
//}
Declaraciones
Se recomienda una declaración por línea, ya que facilita los comentarios.
Inicialización
Intentar inicializar las variables locales donde se declaran. La única razón para no inicializar
una variable donde se declara es si el valor inicial depende de algunos cálculos que deben
ocurrir.
Colocación
Poner las declaraciones solo al principio de los bloques (un bloque es cualquier código
encerrado por llaves "{" y "}".)
Evitar las declaraciones locales que ocultan declaraciones de niveles superiores.
Declaraciones de class e interfaces
Sentencias
Sentencias simples
Cada línea debe contener como mucho una sentencia.
Sentencias compuestas
Las sentencias compuestas son sentencias que contienen listas de sentencias encerradas
entre llaves.
• Las sentencias encerradas deben indentarse un nivel más que la sentencia compuesta.
• La llave de apertura se debe poner al final de la línea que comienza la sentencia
compuesta; la llave de cierre debe empezar una nueva línea y ser indentada al mismo
nivel que el principio de la sentencia compuesta.

• Las llaves se usan en todas las sentencias, incluso las simples, cuando forman parte de
una estructura de control, como en las sentencias if-else o for. Esto hace más sencillo
añadir sentencias sin incluir bugs accidentalmente por olvidar las llaves.
Sentencias de retorno
Una sentencia return con un valor no debe usar paréntesis a menos que hagan el valor de
retorno más obvio de alguna manera.

Sentencias if, if-else, if else-if else

if (condicion) {
sentencias;
}

if (condicion) {
sentencias;
}
else {
sentencias;
}

if (condicion) {
sentencia;
}
else if (condicion) {
sentencia;
}
else{
sentencia;
}
Sentencias for
for (inicializacion; condicion; actualizacion) {
sentencias;
}
Sentencias while
while (condicion) {
sentencias;
}
Sentencias do-while
do {
sentencias;
} while (condicion);
Sentencias switch
switch (condicion)
{
case ABC:
sentencias;
/* este caso se propaga */
case DEF:
sentencias;
break;
case XYZ:
sentencias;
break;
default:
sentencias;
break;
}
Sentencias try-catch
try {
sentencias;
} catch (ExceptionClass e) {
sentencias;
}

Espacios en blanco
Las líneas en blanco mejoran la facilidad de lectura separando secciones de código que están
lógicamente relacionadas.
Se deben usar siempre dos líneas en blanco en las siguientes circunstancias:
• Entre las secciones de un fichero fuente
• Entre las definiciones de clases e interfaces.
Se debe usar siempre una línea en blanco en las siguientes circunstancias:
• Entre métodos
• Entre las variables locales de un método y su primera sentencia
• Antes de un comentario de bloque
Espacios en blanco
Se deben usar espacios en blanco en las siguientes circunstancias:
 • Una palabra clave del lenguaje seguida por un paréntesis debe separarse por un
espacio.

• Debe aparecer un espacio en blanco después de cada coma en las listas de

argumentos.
• Todos los operadores binarios excepto. se deben separar de sus operandos con
espacios en blanco. Los espacios en blanco no deben separadar los operadores
unarios, incremento ("++") y decremento ("--") de sus operandos.

• Las expresiones en una sentencia for se deben separar con espacios en blanco.
Los "Cast"s deben ir seguidos de un espacio en blanco

Convenciones de Nombres
Convenciones Clases e Interfaces.
Las clases
La primera letra debe ser mayúscula
Utiliza nomenclatura camelCase
Para las clases, los nombres deben de ser sustantivos (Sujeto) y van después de la palabra
reservada class
Para las interfaces, los nombres deben de ser adjetivos (Califica el sustantivo) y van después
de la palabra reservada interface

Ej: class Persona

class ClasePrincipal
class VentanaRegistro
interface ActionListener
interface MouseInputListener

Convenciones en Paquetes.
Los paquetes.
Deben ser escritos todo en minúscula.
Van después de la palabra reservada package
Si se van a usar paquetes dentro de otros paquetes, se unen mediante un punto (.)
Finalizan con ;

Ej: package ventanas;

package vo;
package dao;
package imagenes.iconos;

Convenciones en Métodos.
Los métodos
La primer letra debe ser minúscula
Utiliza nomenclatura camelCase
Los nombres deben conformarse por el par verbo + sustantivo
el nombre va después del tipo de método (void, int, double, String)
al finalizar el nombre del método debe indicarse mediante paréntesis con o sin argumentos ()

Ej: void miMetodo()

int sumaEnteros(int a, int b)
Sting mensaje(String saludo)
boolean retornaPermisos(int tipoUsuario)

Convenciones en Variables.
Las variables
La primer letra debe ser minúscula
Utiliza nomenclatura camelCase
el nombre va después del tipo de dato (int, String, double, boolean)
Es recomendable utilizar nombres con un significado explícito, y en lo posible, cortos

Ej: int edad

String nombre
String direccionResidencia
boolean resultadoPrueba

Convenciones en Constantes.
Las constantes
Todas las letras de cada palabra deben estar en mayúsculas
Se separa cada palabra con un _
se declaran similar a las variables, con la diferencia de que el tipo de dato va después de la
palabra reservada final.

Ej: final int EDAD

final String CODIGO_CIUDAD
final double PI

Conclusiones personales:
Las convenciones pueden proporcionar información sobre la función del identificador, por
ejemplo, si es una constante, un paquete o una clase, lo que puede ayudarnos a entender el
código.