Your SlideShare is downloading. ×
Jcc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Jcc

189
views

Published on

Published in: Technology, News & Politics

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
189
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Code Conventions for the Java Programming Language   Equipo de Arquitectura
  • 2. Por qué?
    • El 80% del coste del tiempo de vida de una pieza de software se va en mantenimiento.
    • Casi nunca ningún software es mantenido durante toda su vida por su autor original.
    • Las convenciones de nombrado mejoran la lectura del software, permitiendo a los ingenieros entender el nuevo código más rápidamente y mejor.
    • Si lanzamos nuestro código fuente como un producto, necesitamos asegurarnos de que está tan bien empaquetado y limpio como cualquier otro producto que creemos.
  • 3. Clases/Interfaces Los nombres de clases deberían ser sustantivos, incluyendo mayúsculas y minúsculas con la primer letra de cada palabra interna en mayúscula. Intente mantener los nombres de clases sencillos y descriptivos. Utilice palabras completas y evite usar acrónimos y abreviaturas (a menos que la abreviatura sea ampliamente usada más que la forma completa, tal como URL o HTML). <<class>> Persona atributos métodos
  • 4. Métodos Los nombres de los métodos deberían ser verbos, mezclas de mayúsculas y minúsculas con la primer letra en minúscula y la primer letra de cada palabra interna en mayúscula ( CamelCase ). <<class>> Persona atributos calcularEdad() obtenerRut()
  • 5. Variables Todas las instancias, clases y constantes de clase se escriben usando mayúsculas y minúsculas con la primer letra en minúscula.  Las palabras internas comienzan con letras mayúsculas. Los nombres de variable no deben comenzar con caracteres underscore _ o signo de dólar $ , aunque ambos estén permitidos. Los nombres de variables deberían ser cortos pero con un significado claro. La elección de un nombre de variable debería ser mnemónica, es decir, diseñado para indicar al observador casual su utilización. Deberían evitarse los nombres de variable de un solo caracter excepto para las variables temporales. Algunos nombres de variables temporales son i , j , k , m , y n para enteros; c , d , y e para caracteres.
  • 6. Constantes Los nombres de variables declarados como constantes de clase y las constantes ANSI deberían escribirse todas en mayúsculas con palabras separadas por underscores _ . (Las constantes ANSI deberían evitarse, para facilitar la depuración.) static final int MIN_WIDTH = 4; static final int MAX_WIDTH = 999; static final int GET_THE_CPU = 1;
  • 7. Constantes Los nombres de variables declarados como constantes de clase y las constantes ANSI deberían escribirse todas en mayúsculas con palabras separadas por underscores _ . (Las constantes ANSI deberían evitarse, para facilitar la depuración.) static final int MIN_WIDTH = 4; static final int MAX_WIDTH = 999; static final int GET_THE_CPU = 1;
  • 8. Package’s and Import’s
    • Las primeras líneas no comentadas de un archivo Java, correspoden a una
    • Package o bien a un Import.
    • El paquete debe ser descriptivo, inicialmente el pais, la institución, la
    • Aplicación y luego el detalle de los aplicativos.
    • Los import funcionan para “traer” las clases necesarias en tiempo de
    • ejecución, por ende, SÓLO se debe importar lo que se va a usar. Sentencias
    • como import cl.*; no están permitidas.
    package cl.bch.gwt.consultasaldo.client; import java.util.Map; Import java.util.*; //no se acepta!!!
  • 9. Declaraciones de clase e interfaz package cl.bch.gwt.consultasaldo.client; Import java.util.Map; /** * Comentarios de Javadoc * */ public class/interface Nombre { Variables de clase(static); Variables de instancia (public, protected, package, private); Constructores (por default primero); Métodos (agrupados por funcionalidad) }
  • 10. Código
    • Tabulación
    • La unidad de tabulación deberían ser cuatro espacios.
    • La forma exacta de la tabulación (espacios ó tabuladores) no se especifica.
    • Longitud de línea
    • Evitar las líneas de más de 80 caracteres, ya que algunas herramientas no las manejan bien.
    • Ruptura de líneas (Wrapping lines)
    • Cuando una expresión no cabe en una única línea, se debe romper de acuerdo a estos principios generales:
    • Romper después de una coma.
    • Romper antes de un operador.
    • Alinear la nueva línea con el principio de la expresión al mismo nivel que la línea anterior.
    • Si las reglas anteriores llevan a un código confuso o demasiado pegado al margen derecho, entonces tabular sólo con 8 espacios.
  • 11. Código someMethod(longExpression1, longExpression2, longExpression3, longExpression4, longExpression5); var = someMethod1(longExpression1, someMethod2(longExpression2, longExpression3)); longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6; // RECOMENDADA longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6; // EVITAR
  • 12. Código // NO UTILIZAR ESTA TABULACION if ((condition1 && condition2) || (condition3 && condition4) ||!(condition5 && condition6)) { doSomethingAboutIt(); } // USAR ESTA TABULACION EN SU LUGAR if ((condition1 && condition2) || (condition3 && condition4) ||!(condition5 && condition6)) { doSomethingAboutIt(); } // O USAR ESTA OTRA if ((condition1 && condition2) || (condition3 && condition4) ||!(condition5 && condition6)) { doSomethingAboutIt(); }
  • 13. Código Aquí se muestran tres maneras aceptables de escribir expresiones ternarias: alpha = (aLongBooleanExpression) ? beta : gamma; alpha = (aLongBooleanExpression) ? beta : gamma; alpha = (aLongBooleanExpression) ? beta : gamma;
  • 14. Comentarios
    • Los “ programas ” en Java pueden tener dos tipos de comentarios:
      • comentarios de implementación
      • comentarios de documentación.
    • Los comentarios de documentación (conocidos como &quot;comentarios
    • Javadoc&quot;) son específicos de Java y están delimitados por
        • /**
        • * Comentario de Javadoc.
        • *
        • */
    • Los comentarios de documentación se pueden extraer a HTML
    • usando la herramienta javadoc.
  • 15. Comentarios
    • Los “ programas ” pueden tener cuatro estilos de comentarios de implementación: de bloque ( block comments ), de una sola línea ( single-line comments ), por detrás ( trailing comments ) y de final de línea ( end-of-line comments ).
        • /*
        • * Este es un comentario de bloque
        • */
        • /* Comentario de una sola línea. */
        • // Comentario de una sola línea.
            • if (a == 2) {
            • return true; /* comentario por detrás */
            • } else {
            • //comentario de fin de línea.
            • return isPrime(a); // comentario de fin de línea.
            • }
  • 16. Declaración de variables y/o atributos
    • Se recomienda una declaración por línea ya que fomenta los comentarios. En otras palabras,
    • int level; // nivel de tabulación
    • int size; // tamaño de la tabla
    • Es preferido antes que:
    • int level, size;
    • No poner tipos diferentes en la misma línea. Por ejemplo:
    • int foo, fooarray[]; // ¡MAL!
    • Inicialización
    • Hay que intentar inicializar las variables locales donde se declaren. La única razón para no inicializar una variable donde se declara es si el valor inicial depende de algún cálculo que debe ocurrir primero.
    • Colocación
    • Poner las declaraciones sólo al principio de los bloques.
  • 17. Declaración de clase e interfaz
    • Mientras se codifican clases e interfaces Java, se deberían seguir las siguientes reglas de formato:
      • Ningún espacio entre el nombre del método y el paréntesis &quot;(&quot; que abre su lista de parámetros.
      • La llave de apertura &quot;{&quot; aparece al final de la misma línea que la sentencia de declaración.
      • La llave de cierre &quot;}&quot; comienza una línea nueva tabulada para coincidir con su sentencia de apertura correspondiente, excepto cuando es un bloque vacío que la llave de cierre &quot;}&quot; debería aparecer inmediatamente después de la de apertura &quot;{&quot;.
      • Los métodos están separados por una línea en blanco
  • 18. Sentencias
    • Sentencias simples
    • Cada línea debería contener una sentencia como mucho. Por ejemplo:
    • argv++; // Correcto
    • argc--; // Correcto
    • argv++; argc--; // ¡EVITAR!
    • Sentencias compuestas
    • Las sentencias compuestas son sentencias que contienen una lista de sentencias encerradas entre llaves &quot;{&quot; y &quot;}&quot;.
      • Las sentencias internas deberían estar tabuladas un nivel más que la sentencia compuesta.
      • La llave de apertura debería estar al final de la línea que comienza la sentencia compuesta; la llave de cierre debería estar en una nueva línea y estar tabulada al nivel del principio de la sentencia compuesta.
      • Las llaves se usan en todas las sentencias compuestas, incluídas las sentencias únicas
  • 19. Sentencias
    • Sentencias if, if-else, if-else-if-else:
        • if (condición) {
        • sentencias;
        • }
        • if (condición) {
        • sentencias;
        • } else {
        • sentencias;
        • }
    Nota: Las sentencias if siempre llevan llaves {}. Evitar la siguiente forma, propensa a errores: if (condición) // ¡EVITAR OMITIR LAS LLAVES! {} sentencia;
        • if (condición) {
        • sentencias;
        • } else if (condición) {
        • sentencias;
        • } else {
        • sentencias;
        • }
  • 20. Sentencias
    • Sentencias for
    • Una sentencia for debería tener el siguiente formato:
        • for (inicialización; condición; actualización) {
        • sentencias;
        • }
    • Una sentencia for vacía (aquella en la que todo el trabajo se hace en las cláusulas de inicialización,
    • condición y actualización) debería tener el siguiente formato:
    • for (inicialización; condición; actualización);
  • 21. Sentencias
    • Sentencias while
    • Una sentencia while debería tener el siguiente formato:
        • while (condición) {
        • sentencias;
        • }
    • Una sentencia while vacía debería tener el siguiente formato:
    • while (condición);
  • 22. Sentencias
    • Sentencias switch
    • Una sentencia switch debería tener el siguiente formato:
          • switch (condición) {
          • case ABC:
          • sentencias;
          • /* continua con el siguiente */
          • case DEF:
          • sentencias;
          • break;
          • case XYZ:
          • sentencias;
          • break;
          • default:
          • sentencias;
          • break;
          • }
  • 23. Dudas? Equipo de Arquitectura