Changes between Version 1 and Version 2 of EstandaresDesarrollo


Ignore:
Timestamp:
Aug 25, 2014, 4:58:19 PM (10 years ago)
Author:
admin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • EstandaresDesarrollo

    v1 v2  
    66
    77
    8 
    9 [A continuación se deben identificar los estándares de desarrollo que serán implementados en el desarrollo de la aplicación]
     8'''MAPA DE MERCANCÍA DEL ECO ALBA-TCP'''
     9
     10
     11Dados 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. 
     12
     13
     14Como 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:
     15
     16Espacios
     17
     18
     19 * Usa 4 espacios en blanco como unidad para la indentación, sólo use espacios en blanco no use tabulaciones.
     20 * Todas las líneas deben tener como máximo 79 caracteres.
     21 * 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.
     22 * Evite espacios en blanco en las siguientes situaciones:
     23  * Inmediatamente dentro de paréntesis, corchetes o llaves.
     24
     25
     26
     27                  spam(ham[1], {eggs: 2})
     28
     29
     30
     31  * Inmediatamente antes de una coma, punto y coma o dos puntos.
     32
     33
     34
     35                  if x == 4: print x, y; x, y = y, x
     36
     37
     38
     39  * Inmediatamente antes del paréntesis/corchete que abre una lista de argumentos de una función/lista de índices.
     40
     41
     42
     43                  spam(1)
     44
     45                  dict['key'] = list[index]
     46
     47
     48
     49  * 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.
     50
     51
     52
     53                  x = 1
     54
     55                  y = 2
     56
     57                  long_variable = 3
     58
     59
     60
     61 * Evite colocar múltiples sentencias en una misma línea. Utilice un estilo como el siguiente:
     62
     63
     64
     65                  if cad == 'bla':
     66
     67                      haga_esto()
     68
     69                      haga_uno()
     70
     71                      haga_dos()
     72
     73                      haga_tres()
     74
     75
     76
     77Codificación de caracteres
     78
     79
     80
     81 * 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.
     82
     83
     84
     85Importación de archivos
     86
     87
     88
     89 * 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:
     90
     91
     92
     93  import sys
     94
     95  import snap
     96
     97
     98
     99 * Debes colocar una línea en blanco entre cada grupo de imports, el orden de los grupos de imports debería ser el siguiente:
     100 * Importaciones de librerías estándar
     101 * Importaciones relacionados con terceros
     102 * Importaciones locales específicas de la aplicación/librería.
     103
     104
     105
     106
     107
     108
     109
     110'''Nombramiento'''
     111
     112
     113
     114    '''Paquetes y módulos'''
     115
     116
     117
     118        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.
     119
     120
     121
     122        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.
     123
     124
     125
     126    '''Clases'''
     127
     128
     129
     130        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??.
     131
     132
     133
     134'''    Métodos y Funciones'''
     135
     136
     137
     138        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.
     139
     140
     141
     142    '''Constantes'''
     143
     144
     145
     146        Las constantes deben contener todas sus letras en mayúsculas con carácter de subrayado para separar palabras, por ejemplo: MAX_OVERFLOW y TOTAL.
     147
     148
     149
     150   '''Comentarios '''
     151
     152
     153
     154        Siempre que modifique su código actualice los comentarios!
     155
     156
     157
     158        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.
     159
     160
     161
     162        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).
     163
     164
     165
     166        Los párrafos dentro de un bloque de comentario se separan con una línea que sólo contiene un #.
     167
     168
     169
     170        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.
     171
     172
     173
     174'''Docstring'''
     175
     176
     177
     178        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.
     179
     180
     181
     182        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.
     183
     184
     185
     186        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.
     187
     188
     189
     190        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:
     191
     192
     193
     194      """Retorna la velocidad del viento
     195
     196       Las gráficas opcionales indican la ubicación de los elementos.
     197
     198      """
     199
     200
     201
     202'''Estándares de Interfaz '''
     203
     204'''Versión de HTML '''
     205
     206
     207
     208        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.
     209
     210
     211
     212'''Consideraciones de Navegabilidad '''
     213
     214
     215
     216        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:
     217
     218
     219
     220 * Una ruta de acceso que permita mostrar el trazado de las páginas visitadas desde la de inicio hasta la página actual.
     221 * 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.
     222 * Un mapa de navegación que refleje la estructura organizativa del contenido de la aplicación.
     223
     224
     225
     226'''Diagramación Gráfica '''
     227
     228
     229
     230        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.
     231
     232
     233
     234Adicionalmente se utilizarán los siguientes aspectos:
     235
     236
     237
     238 * Tipografía: Solo se utilizarán estilos de letras de código abierto que no dispongan de licencia restrictiva.
     239 * 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.
     240 * 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.
     241
     242
     243
     244'''Juego de carácteres '''
     245
     246
     247
     248Para la interfaz de la aplicación, reportes, campos de texto, etc. Se utilizarán las espcificaciones Unicode 8 bit (UTF-8).
     249
     250
     251
     252'''Lenguaje de Scripts '''
     253
     254
     255
     256Se 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".
     257
     258
     259
     260'''Elementos añadibles '''
     261
     262
     263
     264En 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.
     265
     266
     267
     268'''Hojas de Estilo en Cascada (CSS) '''
     269
     270
     271
     272Para 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.
     273
     274
     275
     276'''Meta Etiquetas '''
     277
     278
     279
     280Las meta etiquetas serán utilizadas en el encabezado de los documentos de hipertexto, y las mismas levarán la siguiente información:
     281
     282
     283
     284 * Identificación de la aplicación.
     285 * Palabras clave.
     286 * Nombre de la Aplicación.
     287 * Nombre del Órgano o Ente encargado de su desarrollo y mantenimiento.
     288
     289
     290
     291'''Referencias '''
     292
     293
     294
     295 * Manual de Aplicaciones Básicas Ministerio del Poder Popular para la Comunicación y la Información
     296 * Gaceta Oficial 39.109 pag.29 y 30
     297 * Guía general para desarrolladores Python.
     298 * PEP 257 Propuesta de mejora de Python sobre Convenciones de Docstrings. David Goodger y Guido van Rossum.
     299 * PEP-8 Propuesta de mejora de Python sobre Guía de estilo para la codificación en Python. Guido van Rossum y Barry Warsaw.
     300