Estandar de Programación y Código Fuente del Proyecto SIACE

SISTEMA INTEGRAL ADMINISTRATIVO DE
CONTRALORIAS DE ESTADO
(SIACE)
Página Elaboración
1/23 16/03/2011
ESTANDAR DE PROGRAMACIÓN Y
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
ESTANDAR DE PROGRAMACIÓN Y CÓDIGO FUENTE
SIACE
Versión 2.0
Agosto de 2015
La información contenida en este documento es propiedad intelectual de las Contralorías de estados Orientales de Venezuela
Se prohíbe la reproducción total o parcial del mismo, sin consentimiento explícito de las mismas.
ENCUENTRO DE CONTRALORÍAS ORIENTALES-ENCOOVE – TODOS LOS DERECHOS RESERVADOS 2015.

(SIACE)
2/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
HISTORIAL DE REVISIÓN
FECHA VERSIÓN DESCRIPCIÓN AUTOR CARGO CONTRALORIA
07/07/2015 1.0 Formalización del Manual ENCOOVE ENCOOVE ENCOOVE
05/08/2015 1.1 Actualización del diagrama e
estructura de carpetas y el
acuerdo elaboración de css por
módulo
DEIVIS MILLAN ASISTENTE DE PLANIFICACIN Y
TELEMÁTICA I
MONAGAS
10/08/2015 2.0 Actualización de nombramiento de
clases y archivos, restricciones de
nombramiento y llaves en la
estructura del archivo de
codificación
DEIVIS MILLAN ASISTENTE DE PLANIFICACIN Y
TELEMÁTICA I
MONAGAS

(SIACE)
3/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
    Con la firme intención de mantener un orden y homogeneidad en la programación y edición de
código fuente en la reingeniería del Sistema Integral Administrativo de Contralorías Estadales (SIACE)
se establecen los siguientes lineamientos:
• Los lenguajes de programación y herramientas a ser implementados en el desarrollo de la
aplicación son los siguientes:
1. PHP (Hypertext Preprocessor) para sitios web y aplicaciones cliente servidor.
2. SQL, rutinas de bases de datos.
3. JAVASCRIPTS,  rutinas de script en lado del cliente por defecto para navegadores.
4. CSS, hojas de estilos en cascada.
5. HTML5, lenguaje de hipertexto en su versión 5.
6. Cualquier otro necesario para cumplir los lineamientos institucionales y que respete las
directrices emanadas de la Ley de Infogobierno.
• La tecnología de manipulación de datos a implementarse en el desarrollo, sera AJAX
(Asynchronous JavaScript and XML).
• Por razones de seguridad el desarrollo de la aplicación Web, no se amarrará a ningún
framework, será libre y documentada, sobre su lenguaje de desarrollo.
• El desarrollo debe tener los planos arquitectónicos, documentos, entrevistas y cualquier otro que
justiﬁque el dominio de la aplicación y que este relacionado con la metodología de desarrollo.
• El desarrollo  debe tener documentado su código fuente, es decir cada una de sus funciones y
estructuras de datos, archivos de conﬁguración e interfaz así como los estilos, fuentes,
imágenes, galerías, base de datos, planos y cualquier artefacto asociado al proyecto de
desarrollo.

(SIACE)
4/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
• El desarrollo debe partir de un proyecto bien elaborado basado en una metodología y con
estimaciones adecuadas de tiempo, personal y recursos, para garantizar su funcionalidad y
aplicación.
• La aplicación antes de ser liberada debe pasar por un conjunto de pruebas diseñadas y
certiﬁcadas, tanto por la Dirección Técnica, como por las Dependencias y usuarios ﬁnales.
• Se utilizará durante el desarrollo un Sistemas de Control de Versiones (SCV) .
• Todos los cambios de versiones en la aplicación deben identificarse y mantenerse registrados en
una bitácora detallada de cambios entre las versiones. (ver Anexo A1).
• El paradigma de programación que se debe usar en el desarrollo de la aplicación es el orientado
a objeto.
• El diseño de la aplicación debe estar orientado y estructurado de manera ordenada y que
permita la parametrización y el ajuste del sistema a través de archivos de configuración (Ver
Imagen 1).

(SIACE)
5/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
Imagen 1. Estructura Organizacional de Carpetas del SIACE

(SIACE)
6/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
• Todo archivo de la aplicación debe tener un encabezado en comentario que contenga
información relevante acerca de funcionalidad, modulo, programador acerca del sistema.
Ejemplo:
Imagen 2. Encabezado en comentario de los archivos del sistema.
• Todo archivo de la aplicación debe tener un comentario que contenga información relevante
acerca de la actualización realizada.
Imagen 3. Comentario de modificación de los archivos del sistema.

(SIACE)
7/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
• Las aplicación debe ser multiplataforma y debe ejecutarse perfectamente en cualquier
navegador (multinavegador).
• Se debe evitar nombres de archivos con caracteres especiales (por ejemplo, ñ, /, acentos,
espacios). Ejemplo: año.php.
• Se utilizara como hojas de estilo general la librería Bootstrap para mantener la uniformidad en
todo el sistema.
• Se debe heredar la plantilla (interfaz) de estructura del sistema para los módulos, por
consiguiente considerando la librería bootstrap se creara un css para toda la aplicación, y uno
para los módulos en caso de necesitar adecuaciones especificas.
• Las consultas a base de datos deben ser a través de clases.
• Todo comando de JavaScript debe terminar en punto y coma (;).
• Es obligatorio utilizar llaves “{}" por bloques de instrucciones. Incluso, cuando sea un solo
comando.
• Evitar, en la medida de lo posible, el uso indiscriminado de variables globales. Toda variable
que no se le coloque la palabra var, dentro de una función, son variables globales.
• Evitar el uso de eval, ya que esta practica ralentiza los tiempos de respuesta en el navegador.
• Se debe elaborar un solo archivo transaccional o controlador .php por proceso.
• El código debe utilizar una tabulación de 4 espacios.
• No debe haber espacios después del paréntesis de apertura.
• No debe haber espacios antes del paréntesis de cierre.
• Cada vez que se define una variable del DOM colocar al final, la variable igual a NULL para
evitar escape de memoria.

(SIACE)
8/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
Ejemplo:
Imagen 4. Ejemplo de Archivo transaccional o controlador del sistema
GENERALIDADES
• El código PHP DEBE utilizar las etiquetas largas <?php ?>.
• El código PHP DEBE utilizar codificación UTF8.
Un archivo DEBERÍA declarar estructuras (clases, funciones, constantes, etc,...) y no causar
efectos secundarios, o DEBERÍA ejecutar partes de la lógica de negocio, pero NO DEBERÍA hacer las
dos cosas.
La frase "efectos secundarios" significa: que la ejecución de la lógica de negocio no está
directamente relacionado con declarar clases, funciones, constantes, etc, simplemente la de incluir el
archivo.

(SIACE)
9/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
"Efectos secundarios" incluyen, pero no se limitan a: generar salidas, uso explícito de requiere o
include, conexiones a servicios externos, modificación de configuraciones iniciales, enviar errores o
excepciones, modificar variables globales o estáticas, leer o escribir un archivo, etc.
El siguiente ejemplo muestra un archivo que incluye las dos: declaraciones y efectos
secundarios; Un ejemplo de lo que debe evitar:
<?php
// efecto secundario: cambiar configuración inicial
ini_set(E_ALL);
// efecto secundario: cargar ficheros
include "archivo.php";
// efecto secundario: generar salida
echo "<html>n";
// declaración
function contenido(){
    // cuerpo de la función
}
El siguiente ejemplo es el de un archivo que contiene declaraciones sin efectos secundarios; Un
ejemplo que puede seguir:
<?php
// declaración
function contenido(){
}
// una declaración condicional *no* es un
// efecto secundario
if (! function_exists('bar')) {
    function bar(){
    }
}

(SIACE)
10/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
NOMBRE DE LAS CLASES
• El nombre debe identiﬁcar lo que es en singular.
• Los nombres de clases comenzarán con la primera letra en minúscula y el archivo que  contiene
debe tener el mismo nombre. Ejemplo: organismosExternos.php
Clases
class organismosExternos
{
public $atOrganismo;
public function metodo()
{
}
}
NOMBRE DE LAS VARIABLES
Nomenclatura para ambos casos php y javascript en términos de programación lower camelCase ,
la primera letra de la primera palabra en minúscula y si tiene mas de una palabra (la variable) su inicial
después de la primera palabra la letra sera en mayúscula.
ejemplo:
PHP:  $casaGrande
JAVASCRIPT:   casaGrande

(SIACE)
11/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
NOMBRE DE LOS MÉTODOS (metDescripcion)
• El nombre debe identiﬁcar lo que hace, describiendo la acción a realizar.
• Mantener la notación como en el nombre de clase.
• Las tres (3) primeras letras (met ) que identifican los métodos y la descripción de la operación a
realizar.
• El resto del nombre debe mantener la notación como en el nombre de clase.
NOMBRE DE ATRIBUTOS DE CLASE
• Prefije cada atributo con la letras “at”.
• El resto del nombre debe mantener la notación como en el nombre de clase.
Ejemplo:
$atNombre
CONSTANTES
• Su nombre debe identificarla.
• Todas las letras deben ser en mayúsculas.
Ejemplo: define('URL', 'localhost/siaces/');

(SIACE)
12/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
PROGRAMACIÓN
1. Se debe verificar los posibles errores devueltos, por cada llamada al sistema; a menos que se
desee ignorar los errores.
2. No use rutinas largas, descomponga el código en funciones o métodos.
3. Las palabras clave de PHP DEBEN estar en minúsculas.
4. Las constantes de PHP true, false y null DEBEN estar en minúsculas.
ESTRUCTURAS DE CONTROL
Las reglas de estilo para las estructuras de control son las siguientes:
• DEBE haber un espacio después de una palabra clave de estructura de control.
• NO DEBE haber espacios antes del paréntesis de cierre.
• DEBE haber un espacio entre paréntesis de cierre y la llave de apertura.
• El cuerpo de la estructura de control DEBE estar indentado una vez.
El cuerpo de cada estructura DEBE estar encerrado entre llaves. Esto estandariza el aspecto de
las estructuras y reduce la probabilidad de añadir errores como nuevas líneas que se añaden al cuerpo
de la estructura.
If, elseif, else
Una estructura if tendrá el siguiente aspecto. Fíjese en el lugar de los paréntesis, los espacios y
las llaves; y que else y elseif están en la misma línea que las llaves de cierre del cuerpo anterior.
<?php
if ($expr1) {


(SIACE)
13/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
} elseif ($expr2) {

} else {

}
switch ,   case
Una estructura switch tendrá el siguiente aspecto. Fíjese en el lugar donde están los paréntesis,
los espacios y las llaves. La palabra clave case DEBE estar indentada una vez respecto al switch y la
palabra clave break o cualquier otra palabra clave de finalización DEBE estar indentadas al mismo
nivel que el cuerpo del case. DEBE haber un comentario como // no break cuando hay case en cascada
no vacío.
<?php
switch ($expr) {
    case 0:
        echo 'Primer case con break';
        break;
    case 1:
        echo 'Segundo case sin break en cascada';
        // no break
    case 2:
    case 3:
    case 4:
        echo 'Tercer case; con return en vez de break';
        return;
    default:
        echo 'Case por defecto';
        break;
}
while, do while
Una instrucción while tendrá el siguiente aspecto. Fíjese en el lugar donde están los paréntesis,
los espacios y las llaves.

(SIACE)
14/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
<?php
while ($expr) {
    // cuerpo de la estructura
}
<?php
do {
    // cuerpo de la estructura;
} while ($expr);
for
Una sentencia for tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los paréntesis,
los espacios y las llaves.
<?php
for ($i = 0; $i < 10; $i++) {
    // cuerpo del for
}
foreach
Un sentencia foreach tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los
paréntesis, los espacios y las llaves.
<?php
foreach ($iterable as $key => $value) {
    // cuerpo foreach
}
try ,   catch
Un bloque try catch tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los
paréntesis, los espacios y los llaves.
<?php

(SIACE)
15/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
try {
    // cuerpo del try
} catch (PrimerTipoDeExcepcion $e) {
    // cuerpo catch
} catch (OtroTipoDeExcepcion $e) {
    // cuerpo catch
}
Otras Generalidades
• No use paréntesis en la sentencia return. si no es necesario.
• Constructores de objetos:
 No trabaje mucho en los constructores de objetos, solo inicialice variables.
 Los constructores no pueden devolver errores.
• Las funciones deben poder ser reentrantes, es decir que solo utilicen los parámetros que se
envíen a través de ellas, evite usar variables estáticas. Esto es importante para funciones
recursivas.
• Todas las clases deben poseer los métodos get() y set().
Ejemplo:
function __set($variable,$valor){
}
function __get($variable){
}
• Los bloques de declaraciones deben estar alineados:
$mDate    = 0;
$mrDate   = null;

(SIACE)
16/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
$mrName = 0;
$mName  = null;
• Siempre documente bloques nulos de las sentencias for y while. Los bloques nulos son aquellos
que no contienen sentencias;
Ejemplo: while (condicion) {}, while (condicion);
• Siempre use signos de comparación en las condiciones. No asuma valores predeterminados de
una función: 0 para false, 1 para verdadero, etc.
• No veriﬁque un valor booleano por igualdad con 1 (TRUE, YES. SI. etc.); use desigualdad con
0 (FALSO, NO, etc.).
• Trate de evitar asignaciones incrustadas, en condiciones.
Ejemplo: if ((a = b) < c)….. (a=b) es una asignación incrustada en la condición.
• Comentarios:
 Use comentarios en abundancia.
 Deben describir una historia.
 Documentas tus decisiones.
 Palabras Claves:
       :MEJORABLE: Cuando se crea algo feo y pudiera mejorarse luego.
                  :DELICADO: Código delicado que debe tratarse con cuidado, si se desea cambiar.
                  :ADVERTENCIA: Puede generar advertencia.
                 : RESOLVER: Problema con el analizador; el cual deberá ser resuelto.

(SIACE)
17/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
• Todas etiquetas html deben contener el atributo id.
• Las etiquetas html deben ser escritas en minúsculas.
JAVASCRIPT
• El código JavaScript no debería ser embebido en archivos HTML a menos que el código es
específico de una sola sesión. Código en HTML aumenta significativamente pageweight sin
oportunidad para la mitigación de almacenamiento en caché y compresión.
• <script src=filename.js> se debe colocar al final del body o cuerpo de la pagina. Esto reduce los
efectos de las demoras impuestas por la carga de secuencia de comandos en otros componentes
de la página. No hay necesidad de utilizar el idioma o los atributos de texto. Es el servidor, no la
etiqueta script, que determina el tipo MIME.
• La unidad de sangría es de cuatro espacios.
• Evite las lineas de más de 80 caracteres. Cuando una instrucción no cabe en una sola línea,
puede ser necesario para romperlo. Coloque el salto después de un operador, idealmente
después de una coma. Un salto después de un operador disminuye la probabilidad de que un
error de copiar y pegar será enmascarado por la inserción punto y coma. La siguiente línea debe
tener una sangría 8 espacios.
• Todas las variables deben ser declaradas antes de utilizarse. Esto no es requerido por
JavaScript, sin embargo hace que el programa sea más fácil de leer y de detectar las variables
no declaradas que pueden convertirse en variables globales implícitas. Debe minimizarse el uso
de variables globales.
• La declaración de variables debe realizarse al inicio del cuerpo de la función.
• Se prefiere que las variables sean listadas en orden alfabético teniendo su propia línea y
comentario.

(SIACE)
18/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
         var currentEntry;             // currently selected table entry
         var level;        // indentation level
         var size;         // size of table
• JavaScript no tiene ámbito de bloque, por lo que la definición de las variables en bloques puede
confundir a los programadores que tienen experiencia con otras lenguas de la familia C.
• No use en las variables el mismo nombre que el de variables o parámetros de un ámbito
externo. Javascript es feliz en redefinir el nombre, pero aumenta la probabilidad de que el
programa sea leído mal.
• Si un literal de función es anónima, debe haber un espacio entre la función y la palabra
((paréntesis izquierdo). Si el espacio es omitido, entonces puede parecer que el nombre de la función es la
función, que es una lectura incorrecta.
div.onclick = function (e) {
                  return false;
             };
             that = {
                 method: function () {
                 return this.datum;
             },
               datum: 0
             };
• La sentencia with no debe ser utilizada.
• Todos lo operadores binarios excepto '.' (punto) debe ser separado de sus operandos con espacios.
• Ningún espacio debe separar un operador binario y su operando.
• Cada ; (punto y coma) en el elemento de control de una sentencia for debe ser seguido con un espacio.

(SIACE)
19/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
La clase   if   de estados deben tener la siguiente forma:
if (condicion) {
  declaraciones
} else {
  declaraciones
}
if (condicion) {
  declaraciones
} else if (condicion) {
  declaraciones
} else {
  declaraciones
}
Una clase for de estados deben tener la siguiente forma:
for (inicializacion; condicion; update) {
    declaraciones
}
for (variable in object) {
  if (filtro) {
     declaraciones
   }
}
Una sentencia while debería tener la siguiente forma:
      while (condicion) {
declaraciones
}

(SIACE)
20/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
Una sentencia do debería tener la siguiente forma:
do {
declaraciones
} while (condicion);
Una sentencia switch debería tener la siguiente forma:
switch (expresion) {
case expresion:
declaraciones
default:
declaraciones
}
La clase de declaraciones try debe tener la siguiente forma:
try {
declaraciones
} catch (variable) {
declaraciones
}
try {
declaraciones
} catch (variable) {
declaraciones
} finally {
declaraciones
}

(SIACE)
21/23 16/03/2011
CÓDIGO FUENTE
Versión
2.0
Actualización
10/08/2015
ANEXOS

SISTEMA INTEGRAL ADMINISTRATIVO DE CONTRALORIAS DE ESTADO
(SIACE)
Página
22/23
Elaboración
16/03/2011
CONTROL DE CAMBIOS Y MODIFICACIONES DE
SISTEMA
Versión
1
Actualización
10/08/2015
Institución
Proyecto
BITÁCORA DE CAMBIOS
N° Fecha Hora Responsable Versión Módulo Documento Descripción del Cambio
1 DD-MM-YYYY 0:00 xx ARCHIVOS Detalles
2
3
4
5
6

SISTEMA INTEGRAL ADMINISTRATIVO DE CONTRALORIAS DE ESTADO
(SIACE)
Página
23/23
Elaboración
16/03/2011
CONTROL DE CAMBIOS Y MODIFICACIONES DE BASE
DE DATOS
Versión
1
Actualización
10/08/2015
Institución
Proyecto
BITÁCORA DE CAMBIOS
N° Fecha Hora Responsable Versión Módulo Documento Descripción del Cambio
1 11-02-2015 8:00 xx TABLAS MODIFICADAS Detalles
2
3
4
5
6

Estandar de Programación y Código Fuente del Proyecto SIACE

Recomendados

Recomendados

Más contenido relacionado

Similar a Estandar de Programación y Código Fuente del Proyecto SIACE

Similar a Estandar de Programación y Código Fuente del Proyecto SIACE (20)

Último

Último (7)

Estandar de Programación y Código Fuente del Proyecto SIACE