Estándar de Codificación MercSoft

Estándar de Codificación

Tabla de Contenidos

Estándar de Codificación        1

Tabla de Contenidos        2

Generales        3

Árbol de Archivos        3

Comentarios        3

Versionador        3

Modelos        4

Controladores        5

Vistas        5

JavaScript        5

Derechos de Autor        6

Generales

1. El código deberá estar indentado con espacios, no con tabs.
2. 4 espacios por cada nivel de indentación.
3. Todos los nombres de variables, funciones, clases, etc deberán estar en inglés.
4. Los ficheros tienen que ser nombrados en minúsculas utilizando la forma ‘underscore‘ y con su correcta extensión. Ejemplo:  jquery.js, form_validations.js, user_controller.php, dashboard_login.php, global_animations.css

Árbol de Archivos

nombre-proyecto

|_  async

|_  controller

|_  css

|_  js

|_  model

   |_  config.php

   |_  connection.php

|_  resources

|_  vendor

|_  views

   |_  dashboard

   |_  site

Comentarios

1. Se deberá realizar documentación JavaDoc para todos los lenguajes que se utilicen para cada solución.
2. No se deberán subir comentarios al versionador.

Versionador

1. Se utilizará GIT como sistema de gestión de versiones.
2. No es necesario usar interfaz gráfica.
3. Para cada módulo es necesario crear una rama nueva.
4. En caso de haber conflictos, se resolverán por medio de rebasing y se notificará a admin@mercsoft.mx

Modelos

1. Se debe generar un archivo por cada uno de los modelos de página.
2. En cada archivo, se debe agregar un include_once hacia el archivo connection.php
3. Cada que se vaya a enviar información a la vista, se deberá realizar limpieza de datos para asegurar que no se envíen datos truncos.
4. Los métodos que hagan DML (Data Manage Language) que regresen información desde la base de datos (SELECT), deben tener la siguiente estructura:

function get + nombre de tabla + (Si es por campos indicar los campos) () {

    $response = Array(“status”=>false,”message”=>””, nombre_tabla=> Array());

    try {

        $sql = QUERY DESEADA;

        $response[“nombre_tabla”] = $this->executeQueryWithResult($sql);

        $response[“status”] = true;

        if($this->getMessage != “”) {

            $response[“status”] = false;

        $response[“message”] = $this->getMessage();

        }

    } catch($error) {

        $response[“status”] = false;

        $response[“message”] = $error->getMessage();

    }

    return $response;

}

1. En caso de DML que no regresen información (INSERT, UPDATE, DELETE) entonces se debe usar el método $this->executeQueryNoResult(). Quedando con la siguiente estructura:

function [add/modify/delete] + nombre de tabla () {

    $response = Array(“status” => false, “message” => “”);

    try {

        $sql = QUERY A EJECUTAR;

        $response[“status”] = $this->executeQueryNoResult($sql);

        if(!$response[“status”]) {

            $response[“message”] = $this->getMessage();

        }

    } catch($error) {

        $response[“status”] => false;

        $response[“message”] = $error->getMessage();

    }

    return $response;

}

Controladores

1. Se debe generar un archivo control por módulo.
2. La respuesta de todos los métodos de control que se envían a la vista deberán contener al menos los siguientes campos:

1. status: Estado en el que terminó el método de control.
2. system_message: Mensaje de error lanzado ya sea por MySQL o por los bloques try/catch
3. user_message: Mensaje de error que se le mostrará al usuario final.
4. error_file: Nombre del archivo donde el error ocurrió
5. stack_trace: Pila de llamadas de donde ocurrió el error.

1. El controlador bajo ninguna circunstancia deberá acceder a elementos de la vista ni del modelo. No deberá tener ninguna impresión más que la respuesta hacia la vista o el manejador de la petición asíncrona.
2. Cada que se vaya a enviar información a la base de datos, se deberá hacer limpieza de datos para prevenir inseguridades y errores de syntaxis.

Vistas

1. Ningún archivo de vista deberá tener procesamiento de información. Si es necesario volver a organizar una respuesta o limpieza de datos, se añadirá una función dentro del controlador utilizado para que lleve a cabo esta función.
2. Se utilizará un archivo de vista por cada plantilla que se desee usar. Las variables globales serán guardadas dentro de la sesión, independientemente de que exista sesión de usuario o no.
3. Se buscará al máximo evitar el uso de Cookies en el sitio. De ser necesario, se notificará por correo electrónico a admin@mercsoft.mx

JavaScript

1. El objeto global se declara según la forma ‘UPPER_CASE’ con guión bajo como separador y precedido del siguiente prefijo “MS_”. Por ejemplo: “MS_INTERVAL”
2. Los subojetos principales que categorizan las funcionalidades, se declaran según la forma ‘UPPER_CASE’ con guión bajo como separador.
3. Las variables tienen que ser nombradas utilizando la forma ‘camelCase‘.
4. Los constructores tienen que ser nombrados utilizando la forma ‘StudlyCaps‘.
5. Las constantes, de haberlas, tienen que ser nombradas en ‘UPPER_CASE’ con guión bajo como separador.
6. Las propiedades tienen que ser nombradas utilizando ‘camelCase‘.
7. Los métodos tienen que ser nombrados utilizando ‘camelCase‘.
8. Se evitará el uso de localStorage a menos que sea necesario para el funcionamiento del sitio. En caso de usar localStorage, se borrará el par creado en cuanto deje de ser utilizado.

   ---

Derechos de Autor

Este documento puede ser libremente leído y almacenado, pero queda estrictamente prohibido su reproducción parcial o total, su distribución sin el consentimiento de MercSoft, traducido o mencionado, de cualquier manera y mediante cualquier método, teniendo la obligación de cumplir las siguientes cláusulas:

...