Difference between revisions of "DesignGuidelines/es"

From Lazarus wiki
Jump to navigationJump to search
Line 11: Line 11:
 
* Puesto que un estilo es más fácil de leer, Lazarus sigue las líneas de la guía de estilo de la codificación de Borland. Por supuesto, casi cualquier persona encontrará algunos aspectos discutibles, que son menos legibles que otros estilos. Eso es cierto, intente seguir por lo menos el 90%.  
 
* Puesto que un estilo es más fácil de leer, Lazarus sigue las líneas de la guía de estilo de la codificación de Borland. Por supuesto, casi cualquier persona encontrará algunos aspectos discutibles, que son menos legibles que otros estilos. Eso es cierto, intente seguir por lo menos el 90%.  
 
* Intente evitar círculos de la unidad. Esto hace más fácil gobernarla y cuando la unidad está creciendo permite partirla.  
 
* Intente evitar círculos de la unidad. Esto hace más fácil gobernarla y cuando la unidad está creciendo permite partirla.  
* Reduzca al mínimo el número de llamadas de interfaces a LCL, al realizar una acción pedida por el LCL. Los interfaces notifican solamente el LCL, nunca fuerzan algo. El LCL decide.  
+
* Reduzca al mínimo el número de llamadas de interfaces al LCL, al realizar una acción pedida por el LCL. Los interfaces notifican solamente al LCL, nunca fuerzan algo. El LCL decide.  
 
* Nombre según la convención, vea [[Nomenclature/es|Nomenclatura]]  
 
* Nombre según la convención, vea [[Nomenclature/es|Nomenclatura]]  
 
* Todo el código debe funcionar con todas comprobaciones (rango, por ejemplo, desbordamiento, apilado). Además esto ayuda a la depuración, algunos usuarios ponen esas comprobaciones en su fpc.cfg, de modo que se aplican a todo Lazarus. Incluyendo los paquetes y los ejemplos.
 
* Todo el código debe funcionar con todas comprobaciones (rango, por ejemplo, desbordamiento, apilado). Además esto ayuda a la depuración, algunos usuarios ponen esas comprobaciones en su fpc.cfg, de modo que se aplican a todo Lazarus. Incluyendo los paquetes y los ejemplos.

Revision as of 08:49, 30 March 2006

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) 한국어 (ko) português (pt) русский (ru)

Pautas de codificación para Lazarus

Esto va dirigido a los desarrolladores de Lazarus:


Estilo de codificación
  • Puesto que un estilo es más fácil de leer, Lazarus sigue las líneas de la guía de estilo de la codificación de Borland. Por supuesto, casi cualquier persona encontrará algunos aspectos discutibles, que son menos legibles que otros estilos. Eso es cierto, intente seguir por lo menos el 90%.
  • Intente evitar círculos de la unidad. Esto hace más fácil gobernarla y cuando la unidad está creciendo permite partirla.
  • Reduzca al mínimo el número de llamadas de interfaces al LCL, al realizar una acción pedida por el LCL. Los interfaces notifican solamente al LCL, nunca fuerzan algo. El LCL decide.
  • Nombre según la convención, vea Nomenclatura
  • Todo el código debe funcionar con todas comprobaciones (rango, por ejemplo, desbordamiento, apilado). Además esto ayuda a la depuración, algunos usuarios ponen esas comprobaciones en su fpc.cfg, de modo que se aplican a todo Lazarus. Incluyendo los paquetes y los ejemplos.


Archivos nuevos
  • Todos los archivos deben comenzar con una cabecera que contiene la licencia y algunas líneas que describen el contenido.
  • Las fuentes del PASCAL deben tener nombres de fichero en minúscula (pas, pp, inc, lfm, lrs)


Archivos Include
  • Deben comenzar con la directiva {%MainUnit}


Paquetes
  • Deben tener una entrada .lpl en packager/globallinks/


Dialogos (formas modales)
  • Se cierran con Escape (si esa tecla no tiene otro cometido)
  • Se define el botón por defecto e Intro lo activa (si esa tecla no tiene otro cometido)
  • El elemento para los diálogos complejos debe ser redimensionable y el tamaño debe ser almacenado


Elementos del Menú Principal
  • Deben tener una tecla en keymapping.pp


La versión autorizada se puede encontrar en [svn de http://svn.freepascal.org/svn/lazarus/trunk/docs/DesignGuidelines.txt]. Se pueden añadir propuestas de mejora en la página de charla (discusión).