Changes between Version 1 and Version 2 of metodologia2015/EstandaresDesarrollo


Ignore:
Timestamp:
Apr 29, 2015, 5:20:59 PM (9 years ago)
Author:
admin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • metodologia2015/EstandaresDesarrollo

    v1 v2  
    11[[TOC(heading=This section pages, WikiStart, metodologia2015/metodologia, noheading, metodologia2015/AnalisisDominio, metodologia2015/PropuestaDesarrollo, metodologia2015/PlanProyecto, metodologia2015/EstandaresDesarrollo, metodologia2015/EspecificacionRequerimiento, metodologia2015/Codificacion, metodologia2015/AnalisisyDiseno, metodologia2015/Pruebas, metodologia2015/Liberacion, heading=Tabla de Contenido)]]
    22
     3
    34= Estándares de Desarrollo del Proyecto =
    45
     
    67
    78
    8 
    9 [A continuación se deben identificar los estándares de desarrollo que serán implementados en el desarrollo de la aplicación]
     9'''MAPA DE MERCANCÍA DEL ECO ALBA-TCP'''
     10
     11
     12Dados los conocimientos adquiridos por parte de los desarrolladores en la programación en sistemas similares y sobre el tema de Mapa Industrial, se recomienda utilizar el lenguaje de programación python y el frameword django, con el  anexo de librerías de dajax y javasript. Por lo cual se establece como punto de partida para los estándares de desarrollo lo establecido por la Fundación Cenditel, sobre codificación en dicho lenguaje, como se establece a continuación. 
     13
     14
     15Como estilo de programación nos apegaremos al PEP-8 (Guía de Estilo para código Python). Algunos de los puntos más importantes a tomar en cuenta al programar en este proyecto son:
     16
     17Espacios
     18
     19
     20 * Usa 4 espacios en blanco como unidad para la indentación, sólo use espacios en blanco no use tabulaciones.
     21 * Todas las líneas deben tener como máximo 79 caracteres.
     22 * Separa las definiciones de clases y funciones con dos líneas en blanco. Las definiciones de métodos dentro de una clase se separan con una sola línea.
     23 * Evite espacios en blanco en las siguientes situaciones:
     24  * Inmediatamente dentro de paréntesis, corchetes o llaves.
     25
     26
     27
     28                  spam(ham[1], {eggs: 2})
     29
     30
     31
     32  * Inmediatamente antes de una coma, punto y coma o dos puntos.
     33
     34
     35
     36                  if x == 4: print x, y; x, y = y, x
     37
     38
     39
     40  * Inmediatamente antes del paréntesis/corchete que abre una lista de argumentos de una función/lista de índices.
     41
     42
     43
     44                  spam(1)
     45
     46                  dict['key'] = list[index]
     47
     48
     49
     50  * Mas de un espacio alrededor de un = o cualquier otro operador (+=, -=, ==, <, >, !=, <>, <=, >=, in, not in, is, is not, and, or, not, -, *, etc.) para alinear el código con otras líneas.
     51
     52
     53
     54                  x = 1
     55
     56                  y = 2
     57
     58                  long_variable = 3
     59
     60
     61
     62 * Evite colocar múltiples sentencias en una misma línea. Utilice un estilo como el siguiente:
     63
     64
     65
     66                  if cad == 'bla':
     67
     68                      haga_esto()
     69
     70                      haga_uno()
     71
     72                      haga_dos()
     73
     74                      haga_tres()
     75
     76
     77
     78Codificación de caracteres
     79
     80
     81
     82 * El código en la distribución del núcleo de Python siempre debería usar la codificación ASCII o Latin-1 (alias ISO-8859-1), para Python 3.0 en adelante debería usarse UTF-8. Los archivos que usan ASCII (o UTF-8, para Python 3.0) no deberían tener una cookie de codificación. Sólo debería usarse Latin-1 (o UTF-8) cuando un comentario o "docstring" necesite mencionar un nombre de autor que requiere Latin-1; de otra forma, se prefiere usar \x, \u o \U escapes para incluir datos no-ASCII en literales de cadenas.
     83
     84
     85
     86Importación de archivos
     87
     88
     89
     90 * Los imports siempre se ponen al principio del archivo, justo después de cualquier comentario o docstrings de módulo, y antes de las constantes y globales del módulo. Coloca los imports en líneas separadas:
     91
     92
     93
     94  import sys
     95
     96  import snap
     97
     98
     99
     100 * Debes colocar una línea en blanco entre cada grupo de imports, el orden de los grupos de imports debería ser el siguiente:
     101 * Importaciones de librerías estándar
     102 * Importaciones relacionados con terceros
     103 * Importaciones locales específicas de la aplicación/librería.
     104
     105
     106
     107
     108
     109
     110
     111'''Nombramiento'''
     112
     113
     114
     115    '''Paquetes y módulos'''
     116
     117
     118
     119        Los módulos deberían tener nombres cortos con todas sus letras minúsculas, podría incluir el carácter de subrayado en el nombre sólo si mejora su legibilidad.
     120
     121
     122
     123        Los paquetes también deberían tener nombres cortos con todas sus letras minúsculas pero no se recomienda utilizar el carácter de subrayado.
     124
     125
     126
     127    '''Clases'''
     128
     129
     130
     131        Los nombres de clases usan la convención de palabras capitalizadas (CamelCase) donde cada palabra inicia con letra mayúscula sin espacios en blanco ni caracteres especiales. Nótese que cuando se usan abreviaciones en este estilo pueden colocarse en mayúsculas todas las letras de la abreviatura, por ejemplo HTTPServerError es mejor que HttpServerError??.
     132
     133
     134
     135'''    Métodos y Funciones'''
     136
     137
     138
     139        Los nombres de funciones deberían tener todas las letras minúsculas sin espacios, con palabras separadas por el carácter de subrayado si es necesario para mayor legibilidad.
     140
     141
     142
     143    '''Constantes'''
     144
     145
     146
     147        Las constantes deben contener todas sus letras en mayúsculas con carácter de subrayado para separar palabras, por ejemplo: MAX_OVERFLOW y TOTAL.
     148
     149
     150
     151   '''Comentarios '''
     152
     153
     154
     155        Siempre que modifique su código actualice los comentarios!
     156
     157
     158
     159        Los comentarios de bloques generalmente se aplican a algún o todo el código que se encuentra seguidamente después de ellos, y se conserva la unidad de indentación al mismo nivel que el código fuente con el que se relacionan.
     160
     161
     162
     163        Cada línea de un bloque de comentario comienza con un # y un espacio en blanco (a menos que haya texto con el nivel de indentación dentro del comentario).
     164
     165
     166
     167        Los párrafos dentro de un bloque de comentario se separan con una línea que sólo contiene un #.
     168
     169
     170
     171        Los comentarios que se hacen en la misma línea del código son innecesarios y generalmente distraen si no contienen información relevante. En caso de necesitar utilizarlos deberían estar separados al menos por dos espacios del código fuente y deben comenzar con un # y un único espacio.
     172
     173
     174
     175'''Docstring'''
     176
     177
     178
     179        Un docstring es una cadena literal que se coloca como primera oración en la definición de un módulo, clase o método. Esa cadena se convierte en el atributo especial doc de ese objeto.
     180
     181
     182
     183        Todos los módulos deberían tener docstrings, y todas las funciones y clases exportadas por un módulo también deberían tener docstrings. Los métodos públicos (incluyendo el constructor init) deberían tener docstrings. Un paquete puede ser documentado en el módulo docstring del archivo init.py en el directorio del paquete.
     184
     185
     186
     187        Escriba docstrings para todos los módulos, funciones, clases y métodos públicos, no es necesario escribirlas para métodos que no son públicos. Estos métodos que no son públicos deberían tener al menos un comentario que describa lo que hace el método, y que aparezca después de la línea def.
     188
     189
     190
     191        El """ que termina un docstring de varias líneas debería estar en una línea única, y preferiblemente precedido de una línea en blanco, por ejemplo:
     192
     193
     194
     195      """Retorna la velocidad del viento
     196
     197       Las gráficas opcionales indican la ubicación de los elementos.
     198
     199      """
     200
     201
     202
     203'''Estándares de Interfaz '''
     204
     205'''Versión de HTML '''
     206
     207
     208
     209        Para la estructura del lenguaje de marcas HTML se usara como formato las especificaciones HTML 4.01 del 24 de diciembre de 1999, o el XHTML 1.0 de fecha 1 de agosto de 2002, de acuerdo a recomendaciones establecidas por la World Wide Web Consortium (W3C). Los mismos deben ser validados con las herramientas en línea disponibles por la W3C.
     210
     211
     212
     213'''Consideraciones de Navegabilidad '''
     214
     215
     216
     217        Para la mejor navegabilidad entre los diferentes módulos que conforman la aplicación a desarrollar es necesario considerar la inclusión de los siguientes puntos:
     218
     219
     220
     221 * Una ruta de acceso que permita mostrar el trazado de las páginas visitadas desde la de inicio hasta la página actual.
     222 * Un botón de inicio que permita ir a la página principal del sistema y el cual debe estar posicionado siempre en el mismo lugar.
     223 * Un mapa de navegación que refleje la estructura organizativa del contenido de la aplicación.
     224
     225
     226
     227'''Diagramación Gráfica '''
     228
     229
     230
     231        En los banners y encabezados de los reportes se seguirá como estándar de desarrollo lo establecido en el Manual de Aplicaciones Básicas del Ministerio del Poder Popular para la Comunicación y la Información, en el cual se establece la disposición de logotipos y posicionamiento de los mismos así como también el ente gubernamental y demás datos que hacen referencia al gobierno nacional.
     232
     233
     234
     235Adicionalmente se utilizarán los siguientes aspectos:
     236
     237
     238
     239 * Tipografía: Solo se utilizarán estilos de letras de código abierto que no dispongan de licencia restrictiva.
     240 * Imágenes: Las imágenes a utilizar dentro de la aplicación deberán ser exclusivamente aquellas en formato PNG (Portable Network Graphics), según lo describe la norma ISO/IEC 15948:2003, dictada por la Organización Internacional para la Estandarización.
     241 * Información alternativa: En el elemento IMG se utilizará el atributo ALT para definir un texto alterno con la finalidad de mejorar el acceso y usabilidad para aquellos usuarios que por alguna razón no puedan apreciar las imágenes de la aplicación.
     242
     243
     244
     245'''Juego de carácteres '''
     246
     247
     248
     249Para la interfaz de la aplicación, reportes, campos de texto, etc. Se utilizarán las espcificaciones Unicode 8 bit (UTF-8).
     250
     251
     252
     253'''Lenguaje de Scripts '''
     254
     255
     256
     257Se utilizará, en el caso de que sea necesario, el lenguaje de scripts JavaScript en versiones igual o mayores a la 1.7 ECMA-262, colocando el código o función desarrollado bajo este lenguaje en un archivo separado y el cual tendrá extensión ".js".
     258
     259
     260
     261'''Elementos añadibles '''
     262
     263
     264
     265En caso de ser requerida la inclusión de controladores, librerías, clases y/o funciones, estas deberán cumplir con la definición de Software Libre en los términos establecidos en el marco legal vigente. No se utilizará dentro del desarrollo del proyecto en ningún momento elementos añadibles que no cumplan con dichas especificaciones.
     266
     267
     268
     269'''Hojas de Estilo en Cascada (CSS) '''
     270
     271
     272
     273Para el desarrollo de las plantillas que permitirán la visualización gráfica de la aplicación, se utilizarán las hojas de estilo en cascada (CSS) en sus versiones CSS1 y CSS2, según lo describe las recomendaciones planteadas por la W3C del 17 de Diciembre de 1996 o del 12 de Mayo de 1998 respectivamente, con la finalidad de facilitar las labores de mantenimiento de la aplicación. Los mismos serán validados en línea por las herramientas dispuestas por la W3C para tal fin.
     274
     275
     276
     277'''Meta Etiquetas '''
     278
     279
     280
     281Las meta etiquetas serán utilizadas en el encabezado de los documentos de hipertexto, y las mismas levarán la siguiente información:
     282
     283
     284
     285 * Identificación de la aplicación.
     286 * Palabras clave.
     287 * Nombre de la Aplicación.
     288 * Nombre del Órgano o Ente encargado de su desarrollo y mantenimiento.
     289
     290
     291
     292'''Referencias '''
     293
     294
     295
     296 * Manual de Aplicaciones Básicas Ministerio del Poder Popular para la Comunicación y la Información
     297 * Gaceta Oficial 39.109 pag.29 y 30
     298 * Guía general para desarrolladores Python.
     299 * PEP 257 Propuesta de mejora de Python sobre Convenciones de Docstrings. David Goodger y Guido van Rossum.
     300 * PEP-8 Propuesta de mejora de Python sobre Guía de estilo para la codificación en Python. Guido van Rossum y Barry Warsaw.