Estándares de programación del sistema.

NOMBRES.

1. Cuando un nombre consta de varias palabras es habitual poner una a continuación de otra,
poniendo con mayúscula la primera letra de la palabra que sigue a otra (Ejemplo:
Institucion_Educativa).

2. Los nombres de clases e interfaces comienzan siempre por mayúscula (Ejemplo: Persona).

3. Los nombres de objetos, los nombres de métodos y variables miembro, y los nombres de
las variables locales de los métodos, comienzan siempre por minúscula (Ejemplos: main(),
ingresar()).

4. Los nombres de las variables finales, es decir de las constantes, se definen siempre con
mayúsculas (Ejemplo: PI).

5. Todos los nombres del código deben estar en español.

6. Salvo en constantes o en identificadores creados por generadores de código, no se utilizará

guíon bajo (_) en los nombres de los identificadores.

7. No se utilizará la abreviación cuando el único ahorro conseguido es de uno o dos

caracteres en el nombre completo.

8. No se usarán nombres cuya única diferencia sea el numeral indicando cualquier posición.
Ejemplo: fichero1, fichero2, etc.

9. La longitud óptima para el nombre de una rutina es entre 7 y 15 caracteres.

10. Las siguientes partículas no se deben aplicar en los nombres de los identificadores:
 Artículo: él, la, los, las, uno, unos, unas, etc.
 Determinantes Demostrativos: este, ese, aquel, etc.
 Determinantes Posesivos: mi, tu, su, etc.
 Cardinales: uno, dos, tres, etc.
 Ordinales: primero, segundo, etc.
11. No se utilizarán ni sufijos ni prefijos en un nombre cuyo propósito sea indicar el tipo de
identificador. Ejemplo: VarEstudiante.

12. Únicamente se utilizará el guíon bajo como primer carácter de un identificador cuando
dicho identificador haya sido generado de manera automática por una herramienta o
framework.

13. En todo momento se utilizarán nombres que sean claros, concretos y libres de
ambigüedades.

14. Cada clase tendrá como nombre un nombre en el sentido gramatical, nunca un verbo.

15. Los nombres de clases que representan excepciones terminarán en el sufijo Exception.

16. El nombre de una clase estará en singular salvo que una instancia de esa clase represente
una multiplicidad de cosas.

17. El nombre de la clase no contendrá detalles sobre la implementación de la misma. Ejemplo:

ArrayEstudiante.

CLASES, RUTINAS, METODOS Y FUNCIONES.

18. Las clases anónimas deben utilizarse de manera limitada, y en ningún caso tener una
longitud superior a media pantalla.

19. Una clase anónima no tendrá más de dos métodos.

20. Un buen nombre para una rutina es aquel que describe todo lo que la rutina hace.

21. Los nombres de los métodos que no retornan valores, consistan en un verbo, seguido del
objeto al que afecta el verbo. Por ejemplo: Mtd_ImprimirPersona.

22. Para los nombres de funciones o métodos que devuelven valores, debe ser un nombre que
describa el valor devuelto. Por ejemplo: Fnt_Impresora_Lista.
23. Cuando existan grupos de funciones que realicen operaciones similares con pequeñas
diferencias, se deberá establecer un sistema de creación de nombres coherentes.

24. No se crearán rutinas mayores a 80 líneas. En esta longitud se incluye todo lo concerniente
al a rutina, como comentarios, líneas en blanco, etc.

25. Cuando una parte de un método deje de ser útil o cambie de planteamiento, se eliminará
totalmente del método, en lugar de dejarla comentada “por si acaso”.

26. Todas las funciones y métodos documentados deben incluir en su documentación las
precondiciones y postcondiciones.

27. Todas las clases deben documentar sus invariantes, o documentar explícitamente la
carencia de los mismos.

28. Todos los métodos que operen con bases de datos deberán documentar su
comportamiento frente a transacciones.

29. Las precondiciones se expresarán de forma que sean claras y verificables.

30. Los parámetros de una rutina deben estar ordenados como sigue:

 Primero los parámetros de entrada o solo lectura.

 Después los parámetros de lectura/escritura.
 Finalmente, los parámetros exclusivamente de salida.

31. No se utilizarán los parámetros como variables de trabajo o temporales.

32. El número máximo de parámetros en una rutina es 7. Un valor superior a este dificulta
enormemente la comprensión de la rutina.

33. Todas las funciones que devuelvan estructuras de datos de cualquier tipo, devolverán una
estructura vacía para indicar ausencia de resultados y nunca Nil/Null.

34. Después de la llamada a un constructor, un objeto debe ser utilizable inmediatamente, sin
que existan acoplamientos de tipo.

35. Igual que en el caso de las rutinas, la longitud recomendada del nombre de una variable
está entre 7 y 16 caracteres. Se dará a las variables un nombre acorde a su significado y
nunca acorde a su tipo.
36. Cada clase debe ir precedida por un comentario que explique su objetivo. Es recomendable
especificar sus elementos como sigue:

 Estructura de los objetos. Primero las variables y luego las constantes.

 Elementos estáticos.
 Constructores.
 Métodos públicos y privados.
 Métodos estáticos.
 Clases internas.

VARIABLES.

37. Se evitará el uso de variables con nombre i, j, k, n, etc. en bucles, independientemente de

la longitud del bucle.

38. No se utilizarán nombres de variables que puedan ser ambiguos.

39. Para designar variables de estado se utilizarán nombres que hagan referencia al objeto y
estado concreto al que se refieran estas variables.

40. Se evitará dar nombres sin sentido a variables temporales. Por ejemplo: temp1, temp2, etc.

41. Las variables booleanas deben tener nombres que sugieran respuestas o contenidos del
tipo S/N.

42. Los nombres de las variables booleanas deben ser positivos.

43. En la declaración de variables, no se harán agrupaciones por tipos, es decir, cada variable
deberá estar con su tipo.

44. Cualquier variable, parámetro o valor de retorno que en un momento dado pueda valer
NULL, se deberá documentar clara y explícitamente que significa NULL.

45. Las variables dependiendo de su alcance se dividen en globales y locales, el nombre de

la variable consta de un prefijo seguido del nombre de la variable definido por el
consultor.

El nombre debe de tener la siguiente sintaxis:

 <ubicación><tipo de dato>_<nombre de la variable>

Los prefijos son los siguientes:

Alcance:
• Global (g)
• Local (l), todas las variables locales pueden omitir el uso de este prefijo

Tipo de Dato:

Nombre Prefijo

String Str

Char Chr

Boolean Bool

Numerico Num

Integer Int

Long Lng

List Lst

Array Arr

Objeto Obj

DateTime Dat

Date Dat

PARAMETROS.

Para nombrar parámetros debe tener la siguiente sintaxis:

P_<tipo de dato>_<nombre del parametro>
CODIGO.

46. El código debe ser legible secuencialmente de arriba hacia abajo. Cuando las llamadas de
las funciones no dependan entre sí, se agruparán a nivel de datos tratados y no a nivel de
operación.

47. Se debe procurar que el tiempo de vida de las variables sea pequeño.

48. No se utilizará un nivel de anidación superior a 4.

49. Las expresiones condicionales complejas deben ser simplificadas usando llamadas a
funciones booleanas o utilizando variables booleanas temporales.

48. La longitud máxima de un bucle en líneas no podrá ser superior a 66 líneas.

49. La alineación se realizará siempre con tabuladores y nunca con espacios. Será un solo
tabulador por nivel.

50. Cuando una sentencia tenga que partirse en más de una línea, el punto de partición se
elegirá de forma que quede claro que la primera línea tiene continuidad en la siguiente.

51. Solo se escribirá una sentencia por línea.

52. Los comentarios no deben repetir el código no formularlo de otra manera, sino que deben
explicar la intención del código.

53. Cada rutina importante debe tener un bloque de comentarios que describa:

 Su contenido.
 Los parámetros que acepta y sus rangos de valores validos, precondiciones.
 El resultado que devuelve, postcondiciones.
 Excepciones que provoca.
 Cualquier efecto secundario, incluyendo cambios en variables globales.
 Incluir, si es posible, un ejemplo de uso.

Para la declaración de los procedimientos debemos de seguir el siguiente estándar para los
mismos.
***************************************************************
NOMBRE:
FECHA Y CREADOR:
DESCIPCION
DETALLE:
MODIFICACION
***************************************************************
Este encabezado debe ser agregado una línea antes de iniciar el procedimiento o la función.

BASES DE DATOS.

54. El acceso a base de datos se realizará siempre mediante pools de conexiones y nunca
mediante conexiones directas.

55. Nunca se guardarán en su totalidad los datos de usuarios concurrentes y paginación de

resultados recuperados en la sesión o asociados al usuario. En su lugar, se almacenará la
consulta utilizada para producir el resultado y se efectuará una “re- query” contra la base de
datos por cada página.

56. Cuando el acceso a un almacén de datos sea transaccional, el bloque de código que inicia
la transacción deberá ser el encargado de cerrarla.

57. No se asumirá que las transacciones no cerradas terminen de forma automática en

rollback, este debe ser explicito.

PAQUETES.

58. No se accederá a las interioridades de ninguna estructura abstracta de datos. Se crearán

procedimientos o funciones para el acceso a datos, por ejemplo:

 obtenerSigEstudiante(Persona)
 obtenerAntEstudiante(Persona)

59. La nomenclatura de los módulos será:

com.empresa.persona.componente1.componente2

Donde componente2 será opcional únicamente en proyectos de muy poca entidad (hasta 15
clases).
60. En cada archivo se debe especificar su contenido:

 Los paquetes (instrucción package).

 Los archivos de biblioteca (Instrucciones import).
 Un comentario explicando el objetivo del archivo.
 Las clases que define en ese archivo.

61. Los componentes de J2EE se deberán empaquetan por separado y se unen en un

Enterprise Archive (EAR) para el despliegue dentro del servidor de aplicaciones. Los
componentes de la web, en detalle, se deberán empaquetar en web application archives
(WAR). Cada WAR contiene los servlets y/o el JSP, un descriptor del despliegue, y
archivos relacionados del recurso.

El WAR tiene el mismo formato que un JavaARchive (JAR). Sin embargo un archivo
eXtensisible del descriptor del despliegue (XML) debe también puede ser creado.

Los archivos estáticos del HTML y JSP se deberán almacenar en el nivel superior del
directorio de la WAR. El directorio WEB-INF debe contener lo siguiente: las clases del
Servidor (los componentes de Servlets, de JavaBean y los archivos relacionados de la
clase de Java) se deberán almacenar en el directorio de WEB-INF/classes.

Los JAR auxiliares se deben almacenar en el directorio de WEB-INF/lib.

web.xml -- el descriptor componente del despliegue se debe almacenar en el directorio

web-inf.

CONTROLES VISUALES.

62. Los controles visuales deben poseer un nombre estándar, el cual se identificara con un
prefijo, seguido por el nombre del control.

Nombre Prefijo

Label Lb

TextBox Txt

ComboBox Cb

ListBox Lst

DialogBox dlg

Option Op
 Checkbox Ch

Command Button Cmd