1.Prefacio

Este documento tiene como objetivo principal proporcionar a los desarrolladores de Delphi un estándar de escritura de código fuente, así como un estándar de nomenclatura para programas y archivos, para que puedan tener un formato consistente a seguir al programar. De esta forma, cada programador escribe código que otros pueden entender.

2. Especificaciones de escritura del programa fuente

2.1. Reglas generales de formato del código fuente.

1).

Sangría significa dos espacios entre cada nivel. No coloque caracteres de tabulación en el código fuente. Esto se debe a que el ancho del carácter de tabulación varía según las diferentes configuraciones y utilidades de administración de código (impresión, documentación, control de versiones, etc.).

Usando el menú Herramientas|Entorno, en la página General del cuadro de diálogo Opciones de entorno, desmarque las casillas de verificación Usar carácter de tabulación y Relleno opcional para que los caracteres de tabulación no se guarden.

2).

Los márgenes están establecidos en 80 caracteres. El código fuente generalmente no excede el margen al escribir una palabra, pero esta regla es más flexible. Siempre que sea posible, las declaraciones de más de una línea deben estar entre comas u operadores. Después de un salto de línea, debe tener una sangría de dos caracteres.

3). comenzar... finalizar la declaración

La declaración de inicio debe estar sola en una línea. Por ejemplo, la primera línea a continuación es incorrecta, pero la segunda línea es correcta:

para i:=0 a 10 comenzar // Incorrecto, comenzar y for están en la misma línea

para i:=0 a 10 hacer // Sí, comenzar en otra línea

comenzar

Un caso especial de esta regla es cuando comenzar es parte de una declaración else, por ejemplo:

si alguna declaración = entonces

comenzar

.

fin

si no, empezar

alguna otra declaración;

fin;

Nota: La declaración final siempre está en una línea separada. Cuando el comienzo no es parte de una declaración else, la declaración final correspondiente tiene la misma sangría que la declaración inicial.

4).Comentarios

Generalmente utilizamos comentarios de bloque de tipo "{...}". Los comentarios de bloque de tipo "(*...*)" anteriores se utilizan para comentar temporalmente el código no utilizado. A partir de Delphi 2, se admite la línea "//". comentarios, si decide no admitir versiones inferiores a Delphi 2.0, puede utilizar el comentario "//".

2.2. Especificaciones y uso de escritura de declaraciones de formato de declaración de Objeto Pascal

1).

No hay espacio entre el corchete de apertura y el siguiente carácter. Asimismo, no hay espacio entre el corchete de cierre y el carácter anterior. El siguiente ejemplo muestra espacios en blanco correctos e incorrectos.

CallPRoc(Aparámetro); // ¡Error!

CallProc(Aparámetro); // ¡Correcto!

No incluya paréntesis adicionales en las declaraciones. En el código fuente, los paréntesis se utilizan sólo cuando realmente son necesarios. Los siguientes ejemplos demuestran el uso correcto e incorrecto:

si (I=42) entonces // Error, los paréntesis son redundantes

si (I=42) o (J=42) entonces // Correcto, se deben usar corchetes

2). Palabras reservadas y palabras clave.

Las palabras reservadas y las palabras clave en el lenguaje Object Pascal siempre están completamente en minúsculas. La siguiente es una lista de palabras reservadas de Delphi 5:

3). Procedimientos y funciones.

(1).

Los nombres de los procedimientos deben comenzar con una letra mayúscula y estar escalonados para aumentar la legibilidad. La siguiente es una forma incorrecta de escribir:

procedimiento este es un nombre de rutina mal formateado;

Simplemente cámbielo a esto:

procedimiento ThisIsMuchMoreReadableRoutineName;

(2) Parámetros formales

(1) Formato

Siempre que sea posible, se deben agrupar parámetros del mismo tipo:

procedimiento Foo(Param1,Param2,Param3:Imteger;Param4:string);

(2) Orden de los parámetros

El orden de los parámetros formales depende principalmente de las reglas de llamada de registros. El parámetro más utilizado debe ser el primer parámetro, ordenado de izquierda a derecha según la frecuencia de uso. Los parámetros de entrada preceden a los parámetros de salida. Los parámetros con un rango grande deben colocarse antes que los parámetros con un rango pequeño. Por ejemplo:

SomeProc(unPlaneta, unContinente, unPaís, unEstado, unaCiudad).

Algunas son excepciones. Por ejemplo, durante el procesamiento de eventos, el parámetro Remitente de tipo TObject suele ser el primer parámetro que se pasa.

(3) Parámetros constantes

Para evitar que el procedimiento modifique los parámetros de registro, matriz, cadena corta o tipo de interfaz, el parámetro formal debe marcarse como Const. De esta forma, el compilador generará código de la forma más eficiente, asegurando que los parámetros pasados ​​sean inmutables.

Si no se espera que el procedimiento modifique otros tipos de parámetros, también se pueden marcar Const. Aunque esto no tiene ningún impacto en la eficiencia, proporciona más información a quien llama al procedimiento.

4).Variables

(1).Variables locales.

Las variables locales se utilizan dentro del procedimiento. Si es necesario, las variables deben inicializarse inmediatamente al ingresar al procedimiento. Las variables de tipo AnsiString locales se inicializan automáticamente en una cadena vacía, las variables de tipo interfaz local y dispinterface se inicializan automáticamente a cero, y las variables de tipo Variant y OleVariant locales se inicializan automáticamente a Sin asignar.

(2).Variables globales

Generalmente se desaconseja el uso de variables globales. Sin embargo, a veces es necesario. Aun así, las variables globales deberían restringirse a los entornos donde se necesitan. Por ejemplo, una variable global puede ser global sólo para la parte de implementación de la unidad.

Los datos globales que serán utilizados por muchas unidades deben trasladarse a una unidad común y ser utilizados por todos los objetos. Los datos globales se pueden inicializar directamente a un valor cuando se declaran. Tenga en cuenta que todas las variables globales se inicializan automáticamente a cero, por lo que no inicialice las variables globales a valores nulos como 0, nulo o Sin asignar. Las variables globales inicializadas a cero no ocupan espacio en el archivo .EXE. Los datos inicializados en cero se almacenan en un segmento de datos virtuales, y el segmento de datos virtuales solo asigna memoria cuando se inicia la aplicación. Los datos globales inicializados distintos de cero ocupan espacio en el archivo .EXE.

5).

(1). Reglas de capitalización.

Los identificadores de tipo son palabras reservadas y deben estar todos en minúsculas. Los tipos de API de Win32 suelen estar completamente en mayúsculas y siguen reglas para nombres de tipos específicos, como Windows.pas u otras unidades de API. Para otros nombres de variables, la primera letra debe estar en mayúscula y las demás letras deben estar en mayúsculas y minúsculas alternas. A continuación se muestran algunos ejemplos:

var

MyString: cadena; // palabras reservadas

WindowsHandle: HWND // Tipo de API Win32

I: Entero; //Identificador de tipo introducido en la unidad del Sistema

(2). Tipo de coma flotante.

Se desaconseja el uso del tipo Real ya que está reservado sólo para compatibilidad con código Pascal anterior. Normalmente, Double debería usarse para números de coma flotante. El procesador puede optimizar Double y es un formato de datos estándar definido por IEEE. Extender se puede utilizar cuando se requiere un rango mayor que el que proporciona Double. Extend es un tipo específico de Intel y no es compatible con Java. Cuando el número físico de bytes de la variable de punto flotante es importante (quizás usando un lenguaje diferente para escribir la DLL), se debe usar Single.

(3).Variante y OleVariante

Generalmente no se recomienda utilizar Variant y OleVariant. Sin embargo, estos dos tipos son necesarios para la programación cuando el tipo de datos se conoce sólo en tiempo de ejecución (a menudo en aplicaciones COM y de bases de datos). Al realizar programación COM, como automatizar controles ActiveX, debe usar OleVariant; para programación que no sea COM, debe usar Variant. Esto se debe a que Variant puede guardar efectivamente las cadenas nativas de Delphi, mientras que OleVariant convierte todas las cadenas en cadenas OLE (es decir, cadenas WideChar) y no tiene función de recuento de referencias.

6).

(1). Si declaración

En una declaración if/then/else, el caso de ejecución más probable debe colocarse en la cláusula then, y el caso menos probable debe colocarse en la cláusula else. Para evitar muchas declaraciones if, utilice declaraciones case en su lugar. Si hay más de 5 niveles, no utilice declaraciones if. Utilice un método más claro en su lugar. No utilice paréntesis adicionales en declaraciones if.

Si hay varias condiciones para probar en una declaración if, deben ordenarse de derecha a izquierda en orden de complejidad computacional. Esto permite que el código aproveche al máximo la lógica de estimación de cortocircuito del compilador. Por ejemplo, si la Condición1 es más rápida que la Condición2 y la Condición2 es más rápida que la Condición3, la declaración if generalmente debería construirse así:

si Condición1 y Condición2 y Condición3 entonces

Si existe una alta probabilidad de que la Condición3 sea Falsa, usando la lógica de estimación de cortocircuito, también podemos poner la Condición3 al frente:

si Condición3 y Condición1 y Condición2 entonces

(2). declaración del caso

(1) Descripción general

Las constantes para cada caso en la declaración del caso deben ordenarse en orden numérico o alfabético. La declaración de acción para cada situación debe ser breve y, por lo general, no debe tener más de 4 o 5 líneas de código. Si la acción es demasiado compleja, el código debe colocarse en un procedimiento o función independiente. La cláusula else de la declaración Case solo se usa para casos predeterminados o detección de errores.

(2) Formato

Las declaraciones de casos siguen reglas normales de sangría y denominación.

(3).

Se recomienda no utilizar el procedimiento Exit para salir del ciclo while. Si es necesario, se debe utilizar una condición de bucle para salir del bucle. Todo el código que inicializa el bucle while debe ubicarse antes de la entrada while y no debe estar separado por declaraciones irrelevantes. Cualquier trabajo auxiliar del negocio deberá realizarse inmediatamente después del ciclo.

(4). para declaración

Si se determina el número de bucles, se debe utilizar una declaración for en lugar de una declaración while.

(5).repetir declaración

La declaración de repetición es similar a un bucle while y sigue las mismas reglas.

(6). con declaración

(1) Descripción general

La declaración with debe usarse con precaución. Evite el uso excesivo de declaraciones with, especialmente cuando utilice múltiples objetos o registros dentro de una declaración with. Por ejemplo:

con Record1, Record2 hacer

Estas situaciones pueden confundir fácilmente a los programadores y dificultar la depuración.

(2) Formato

La declaración with también sigue las reglas de este capítulo para denominación y sangría.

7). Manejo estructurado de excepciones.

(1)

El manejo de excepciones se utiliza principalmente para corregir errores y proteger recursos. Esto significa que dondequiera que se asignen recursos, se debe utilizar try...finally para garantizar que se liberen los recursos. Sin embargo, se hacen excepciones si los recursos se asignan/liberan en la parte inicial/final de la unidad o en el constructor/destructor del objeto.

(2). Uso de intentar... finalmente.

Siempre que sea posible, cada asignación de recursos debe coincidir con una estructura try...finally. Por ejemplo, el siguiente código puede provocar un error:

AlgunaClase1 := TAlgunaClase.Create;

AlgunaClase2 := TAlgunaClase.Crear;

intentar

{hacer algo de código}

finalmente

AlgunaClase1.Gratis;

AlgunaClase2.Gratis;

fin;

Una solución segura para la asignación de recursos anterior es:

AlgunaClase1 := TAlgunaClase.Create;

intentar

AlgunaClase2 := TAlgunaClase.Create;

intentar

{hacer algo de código}

finalmente

AlgunaClase2.Gratis;

fin;

finalmente

AlgunaClase1.Gratis;

fin;

(3). Uso de try...excepto.

Si desea realizar alguna tarea cuando ocurre una excepción, puede usar try...except. Por lo general, no es necesario utilizar try... excepto para simplemente mostrar un mensaje de error, porque el objeto de la aplicación puede hacerlo automáticamente según el contexto. Si desea activar el manejo de excepciones predeterminado en la cláusula, puede activar la excepción nuevamente.

(4). Uso de try...except...else.

Se desaconseja el uso de try...except con una cláusula else porque esto bloqueará todas las excepciones, incluidas las excepciones que no está preparado para manejar.

3. Convención de nomenclatura

3.1. Procedimiento y Función

1).Nombre

Los nombres de procedimientos y funciones deben ser significativos. Es mejor anteponer el nombre del proceso de realización de una acción con el verbo que expresa la acción. Por ejemplo:

procedimiento Formatear disco duro;

El nombre del procedimiento para configurar los valores de los parámetros de entrada debe tener el prefijo Set, por ejemplo:

procedimiento Establecer nombre de usuario;

El nombre del procedimiento para obtener un valor debe tener el prefijo Get, por ejemplo:

función GetUserName:cadena;

2).Parámetros formales

El nombre de todos los parámetros formales debe expresar su propósito. Si procede, el nombre del parámetro formal lleva preferentemente el prefijo a, por ejemplo:

procedimiento SomeProc(aUserName:string; aUserEge:integer);

El prefijo a es necesario cuando el nombre del parámetro tiene el mismo nombre que un atributo o campo de clase.

3).Conflicto de nombres

Cuando dos unidades contienen procedimientos con el mismo nombre, si se llama al procedimiento, en realidad se llama al procedimiento de la unidad que aparece más adelante en la cláusula Usos. Para evitar esto, agregue el nombre de la unidad deseada antes del nombre del método, por ejemplo:

SysUtils.FindClose(SR);

o Windows.FindClose(Manejar);

3.2.

El nombre de una variable debe expresar su propósito. Las variables de control de bucle suelen ser letras únicas, como I, J o K. También puede utilizar un nombre más significativo, como UserIndex. Los nombres de las variables booleanas deben indicar claramente el significado de los valores Verdadero y Falso.

1).Variables locales

Las variables locales siguen las reglas de nomenclatura de otras variables.

2).Variables globales

Las variables globales comienzan con una letra mayúscula "G" y siguen las reglas de denominación de otras variables.

3.3.Tipo

3.3.1.Tipos generales

1). Tipo de enumeración.

El nombre del tipo de enumeración debe representar el propósito de la enumeración. El carácter T debe ir precedido del nombre para indicar que se trata de un tipo de datos. El prefijo de la lista de identificadores del tipo de enumeración debe contener de 2 a 3 caracteres en minúscula para asociarlos entre sí. Por ejemplo:

TSongType=(stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);

El nombre de la instancia de variable del tipo de enumeración es el mismo que el tipo, pero sin el prefijo T. También puede darle a la variable un nombre más especial, como: FavoriteSongTypel, FavoriteSongType2, etc.

3.3.2. Tipo construido

1).Tipo de matriz

El nombre del tipo de matriz debe expresar el propósito de la matriz. Los nombres de los tipos deben tener el prefijo "T". Si desea declarar un puntero a un tipo de matriz, debe anteponerle la letra P y declararlo antes de la declaración de tipo. Por ejemplo:

tipo

PCycleArray = ^TCicleArray;

TCycleArray=matriz[1..100] de número entero;

De hecho, una instancia de variable de un tipo de matriz tiene el mismo nombre que el tipo, pero sin el prefijo "T".

2). tipo de registro

El nombre del tipo de registro debe expresar el propósito del registro. Los nombres de los tipos deben tener como prefijo la letra T. Si desea declarar un puntero a un tipo de registro, debe anteponerle la letra P y declararlo antes de la declaración de tipo. Por ejemplo:

tipo

PEempleado = ^TEmpleado;

Empleado=registro

Nombre del empleado: cadena;

Tarifa de empleado: Doble;

fin;

3.3.3. Tipo de clase (Clase)

1). Denominación y formato.

El nombre de la clase debe expresar el propósito de la clase. Generalmente, se debe agregar la letra "T" antes del nombre de la clase. Si es una clase de interfaz, entonces se debe agregar "I" antes del nombre de la clase. El nombre de la clase de excepción de error se debe agregar con "E". y el tipo de referencia de clase (tipo de referencia de clase) debe agregarse antes del nombre de la clase. Agregue "Clase" después del nombre. Por ejemplo:

tipo

TCliente = clase(TObjeto);

ICliente = interfaz;

TCustomerClass = clase de TCustomer

ECustomerException = clase(Excepción);

El nombre de instancia de una clase suele ser el mismo que el nombre de la clase, sin el prefijo "T".

var

Cliente: TCliente;

Nota: Para nombrar los componentes, consulte "Tipos de componentes".

2).Campo

(1) Denominación y formato

La denominación de campos sigue las mismas reglas que las variables, excepto que se agrega el prefijo F para indicar que se trata de un campo.

(2) Visibilidad

Todos los campos deben ser privados. Si desea acceder a un campo fuera del alcance de una clase, puede hacerlo con la ayuda de los atributos de clase.

3).Método

(1) Denominación y formato

Los métodos de denominación siguen las mismas reglas que los procedimientos y funciones.

(2) método estático

Los métodos estáticos deben usarse cuando no desea que las clases derivadas anulen un método.

(3) Método virtual (virtual) y método dinámico (dinámico)

Cuando desee que las clases derivadas anulen un método, debe utilizar métodos virtuales. Si un método de clase va a ser utilizado directa o indirectamente por varias clases derivadas, se deben utilizar métodos dinámicos (dinámicos). Por ejemplo, si una clase contiene un método que se reemplaza con frecuencia y tiene 100 clases derivadas, el método debe definirse como dinámico, lo que puede reducir la sobrecarga de memoria.

(4) Método abstracto (abstracto)

Si una clase va a crear instancias, no utilice métodos abstractos. Los métodos abstractos sólo se pueden utilizar en clases base que nunca crean instancias.

(5) Método de acceso al atributo

Todos los métodos de acceso a la propiedad deben definirse en la parte privada o protegida de la clase. Los métodos de acceso a la propiedad siguen las mismas reglas que los procedimientos y funciones. Los métodos utilizados para la lectura deben tener el prefijo "Get", los métodos utilizados para la escritura deben tener el prefijo "Set" y tener un parámetro llamado Valor cuyo tipo sea el mismo que el tipo de la propiedad. Por ejemplo:

TSomeClass = clase(TObjeto)

privado

fsomeField: entero;

protegido

función GetSomeField: Entero;

procedimiento SetSomeField(Valor: Entero);

público

propiedad SomeField: entero leer GetSomeField escribir SetSomeField;

fin;

Aunque no es obligatorio, se recomienda utilizar métodos de acceso de escritura para acceder a las propiedades que representan campos privados.

4).Atributos

Las propiedades sirven como accesores a campos privados y siguen las mismas reglas de nomenclatura que los campos, excepto sin el prefijo F. Los nombres de las propiedades deben ser sustantivos, no verbos. Las propiedades son datos y los métodos son acciones. Los nombres de las propiedades de la matriz deben ser plurales, mientras que las propiedades generales deben ser singulares.

3.3.4.Tipo de componente

1). Normas de denominación para tipos de componentes.

La denominación de componentes es similar a la denominación de clases, excepto que cuando entra en conflicto con otros nombres de componentes, puede agregar un prefijo de 3 caracteres para identificar una empresa, individuo u otra entidad. Por ejemplo, un componente de reloj se puede declarar así:

TddgClock = clase(TComponent)

Tenga en cuenta que los tres caracteres del prefijo deben estar en minúsculas.

2). Reglas de nomenclatura para instancias de componentes.

El nombre de la instancia del componente debería poder describir su significado real. La convención de nomenclatura aquí utiliza una convención de nomenclatura de prefijo húngaro modificada. La razón para usar un prefijo en lugar de un sufijo es que es más fácil buscar el nombre del componente en el Inspector de objetos y el Explorador de código que buscar el tipo de componente. En este estándar, el nombre de la instancia del componente consta de dos partes: el prefijo y el identificador del atributo.

(1). Prefijo del componente.

El prefijo de un componente es principalmente una abreviatura del tipo de componente. Consulte los prefijos de los componentes en la siguiente tabla:

Como se muestra arriba, el prefijo de tipo de componente proviene del análisis de las propiedades de tipo que describen el componente. Normalmente, las siguientes reglas describen cómo definir un prefijo de tipo de componente:

• Elimine el prefijo T de los nombres de tipos de componentes. Por ejemplo, TButton se convierte en Button.
• Elimina todas las vocales excepto la primera vocal. Por ejemplo, Botón se convierte en bttn y Editar se convierte en edt.
• Letras dobles comprimidas. Por ejemplo, bttn se convierte en btn.
• En caso de conflicto, se añade una vocal a uno de los prefijos componentes. Por ejemplo, agregue una vocal al prefijo del componente TBatton y cámbiela a batn para distinguir el prefijo de TButton.

• Sin embargo, las reglas anteriores primero deben garantizar que el nombre del prefijo se ajuste a la costumbre, para que el nombre pueda entenderse. Por ejemplo, el prefijo del control TDDEClientConv es una excepción.

Nota: El prefijo de un componente indica el tipo de componente, ya sea un botón, una etiqueta, etc., por lo que no es necesario crear un prefijo de componente para cada clase de componente especial. Por ejemplo, el prefijo de componente de. TMyButton todavía está activado.

(2). Nombre de identificación de la propiedad del componente.

El nombre de identificación de la propiedad del componente es una descripción de la intención del componente. Por ejemplo, una instancia del componente TButton utilizada para cerrar un formulario podría denominarse btnClose. Una instancia del componente de edición de nombre puede denominarse edName.

3.3.5. Tipos de formulario y diálogo

1). Estándares de nomenclatura para tipos de formularios.

El nombre del formulario o tipo de diálogo debe expresar el propósito del formulario, con el prefijo "Tfrm" para un formulario o "Tdlg" para un cuadro de diálogo, seguido de un nombre descriptivo. Por ejemplo, el nombre del tipo de formulario Acerca de es:

TfrmAbout = clase(TForm)

El nombre del tipo del formulario principal es:

TfrmMain = clase(TForm)

El nombre del tipo del formulario de inicio de sesión del cliente es:

TfrmCustomerEntry = clase(TForm)

El nombre del tipo del cuadro de diálogo de inicio de sesión es:

TdlgLogin = clase(TForm)

2). Estándares de nomenclatura para instancias de formulario.

El nombre de la instancia del formulario es el mismo que el nombre del tipo correspondiente, pero sin el prefijo T. Por ejemplo, el nombre del tipo de formulario y la instancia mencionados anteriormente es:

3). Formulario creado automáticamente.

A menos que existan motivos especiales, solo se genera automáticamente el formulario principal. Todos los demás formularios deben eliminarse de la lista generada automáticamente en el cuadro de diálogo Opciones del proyecto. Para obtener más información, consulte las siguientes secciones.

4). Función de creación de instancias de forma modal.

Todas las unidades de formulario deben contener funciones de creación de instancias para crear, configurar, mostrar modal y publicar el formulario. Esta función devolverá el resultado del modo devuelto por el formulario. Los parámetros pasados ​​a esta función siguen las reglas para el paso de parámetros. El motivo de una encapsulación como esta es facilitar la reutilización y el mantenimiento del código.

Las variables del formulario deben eliminarse de la unidad y definirse como variables locales en la función de creación de instancias del formulario (tenga en cuenta que esto requiere que el formulario se elimine de la lista generada automáticamente en el cuadro de diálogo Opciones del proyecto. Consulte el contenido anterior.

Por ejemplo, el siguiente archivo de unidad demuestra la función de creación de instancias GetUserData.

Unidad UserDataFrm;

Interfaz

Usos

Windows, Mensajes, SysUtils, Clases, Gráficos, Controles, Formularios,

Diálogos, StdCtrls;

Tipo

TfrmUserData = clase(TForm)

edtNombre de usuario: TEdit;

edtID de usuario: TEdit;

privado

{Declaraciones privadas}

público

{Declaraciones públicas}

fin;

función GetUserData(var aUserName: String;var aUserID: Integer): Word;

implementación

{$R *.DFM}

función GetUserData(var aUserName: String;var aUserID: Integer): Word;

var

frmUserData: TfrmUserData;

comenzar

frmUserData := TfrmUserData.Create(Aplicación);

frmUserData.Caption:='Obteniendo datos del usuario';

Resultado: = frmUserData.ShowModal;

si Resultado=mrOK entonces

comenzar

aUserName := frmUserData.edtUserName.Text;

aUserID := StrToInt(frmUserData.edtUserID.Text);

fin;

finalmente

frmUserData.Gratis;

fin;

fin;

Fin.

5).Forma de marco y forma compuesta.

Si la estructura de un formulario es demasiado compleja, se debe dividir en un marco de formulario principal y varios marcos de formulario secundarios integrados en el marco de formulario principal. como:

TfrmMainFrame: TfrmInfoFrame, TfrmEditorFrame

El objetivo principal del uso de marcos de formulario es resolver el problema de la interfaz y la reutilización del código, y mejorar la cohesión del código unitario (después de la división, cada marco de formulario es una unidad independiente), mejorando así la calidad de la ingeniería de software. Debe extraer el código relacionado con la interfaz (reutilizable) y el código relacionado con la aplicación (no reutilizable).

3.3.6.Tipo de módulo de datos

1). Estándares de denominación para módulos de datos.

El nombre del tipo de módulo de datos debe expresar su propósito y tener el prefijo "Tdm" seguido de un nombre descriptivo. Por ejemplo, el nombre del tipo del módulo de datos del Cliente es:

TdmCliente = clase(TDataModule)

El nombre del tipo del módulo de datos de Órdenes es:

TdmOrder = clase(TDataModule)

2). Estándares de nomenclatura para instancias de módulos de datos.

El nombre de una instancia de módulo de datos debe ser el mismo que el nombre del tipo correspondiente, pero sin el prefijo T. Por ejemplo, el tipo de módulo de datos anterior y el nombre de instancia son los siguientes:

3.4.Documentos

Se recomienda utilizar información de encabezado de archivo estructurada en todos los archivos fuente, archivos de proyecto y archivos de unidad. El encabezado de un archivo debe contener al menos la siguiente información:

{

Copyright @ Año por Autores

}

3.4.1.Archivos de proyecto

Los nombres de los archivos del proyecto deben ser descriptivos. Por ejemplo, el nombre del proyecto "Administrador de errores de la guía para desarrolladores de Delphi 5" es DDGBugs.dpr y el nombre de un programa de información del sistema es SysInfo.dpr.

3.4.2. Archivo de formulario

El nombre del archivo del formulario debe expresar el propósito del formulario y tener el sufijo Frm. Por ejemplo, el nombre de archivo del formulario Acerca de es AboutFrm.dfm y el nombre de archivo del formulario principal es MainFrm.dfm.

3.4.3.Archivos del módulo de datos

El nombre del archivo del módulo de datos debe expresar la función del módulo de datos y tener un sufijo DM. Por ejemplo, el nombre de archivo del módulo de datos de Clientes es CustomersDM.dfm.

3.4.4.Archivo del módulo de datos remoto

El nombre del archivo del módulo de datos remoto debe expresar el propósito del módulo de datos remoto. Agregue el sufijo RDM después del nombre. Por ejemplo, el archivo del módulo de datos remotos Clientes se denomina ClientesRDM.dfm.

3.4.5.Archivo unitario

1).

(1) Nombre de la unidad

Los nombres de las unidades deben ser descriptivos. Por ejemplo, la unidad de formulario principal de la aplicación se llama MaimFrm.pas.

(2) Cláusula de usos

La cláusula de Usos de la sección Interfaz debe contener solo las unidades requeridas por esa sección. No incluya nombres de unidades que Delphi pueda agregar automáticamente. La cláusula de Usos de la parte de Implementación solo debe contener las unidades necesarias para esta parte y ninguna unidad adicional.

(3) Parte de la interfaz

La sección Interfaz debe contener solo declaraciones de tipos, variables, procedimientos y funciones a las que deben acceder unidades externas. Además, estas declaraciones deben preceder a la sección de Implementación.

(4) Parte de implementación

La parte de Implementación incluye la implementación de tipos privados, variables, procedimientos y funciones de esta unidad.

(5) Parte de inicialización

No coloque código que requiera mucho tiempo en la sección Inicialización. De lo contrario, hará que la aplicación se inicie muy lentamente.

(6) Parte de finalización

Asegúrese de liberar todos los recursos asignados en la sección Inicialización.

2).Unidad de forma

El nombre del archivo de la unidad de formulario es el mismo que el nombre del formulario correspondiente, simplemente cambie el prefijo por el sufijo. Por ejemplo, el nombre de la unidad del formulario Acerca de es AboutFrm.pas. El nombre del archivo de unidad del formulario principal es MainFrm.pas.

3).Unidad del módulo de datos

El nombre del archivo de unidad del módulo de datos es el mismo que el nombre del módulo de datos correspondiente. Por ejemplo, el nombre de la unidad del módulo de datos es ClientesDM.pas.

4).Unidad general

El nombre de una unidad general debe expresar su propósito y debe tener el prefijo "u". Por ejemplo, el nombre de una unidad de herramienta de depuración práctica es uDebugUtilities.pas, y el nombre de la unidad que contiene variables globales es uCustomerGlobals.pas.

Tenga en cuenta que los nombres de las unidades deben ser únicos dentro de un proyecto. Los nombres de unidades comunes no pueden tener el mismo nombre.

5).Unidad componente

(1).

Las celdas de los componentes deben colocarse en rutas separadas para indicar que son las celdas que definen el componente. Generalmente no se colocan en el mismo camino que el proyecto. Los nombres de los archivos de las unidades deben expresar su contenido.

Tenga en cuenta que consulte "Estándares de denominación para tipos de componentes" para obtener más información sobre los estándares de denominación de componentes.

Una celda de componente solo puede contener un componente principal, que es el componente que aparece en la paleta de componentes. También se pueden incluir en la misma unidad otros componentes u objetos auxiliares.

(2). Unidad de registro.

El proceso de registro de componentes debe sacarse de la unidad de componentes y colocarse en una unidad separada. Esta unidad de registro se utiliza para registrar todos los componentes, editores de propiedades, editores de componentes, asistentes, etc.

El registro de componentes debe realizarse en el paquete de diseño. Por lo tanto, la unidad de registro debe incluirse en el paquete de tiempo de diseño en lugar del paquete de tiempo de ejecución. Se recomienda que la unidad de registro se denomine así:

xxxReg.pas

Entre ellos, el prefijo de caracteres xxx se utiliza para identificar el nombre del paquete del componente o la empresa, individuo u otra entidad. Por ejemplo, la unidad de registro se denomina xxxReg.pas.

6). Reglas de nomenclatura de archivos de paquetes (.dpk).

(1). Paquete de tiempo de ejecución y paquete de diseño.

El paquete de ejecución debe contener sólo las unidades necesarias. Esos elementos del editor de propiedades y del editor de componentes deben colocarse en el paquete en tiempo de diseño. Las unidades de registro también deben incluirse en el paquete de la fase de diseño.

(2). Estándares de nomenclatura de archivos.

La denominación de paquetes sigue el siguiente patrón:

dcliiiDescvvCn.pkg —Paquete de diseño

iiiDescvvCn.pkg: paquete de tiempo de ejecución

Entre ellos, iii representa un prefijo de 2 a 3 caracteres, que se utiliza para identificar empresas, personas u otras cosas que deben identificarse. Es opcional; Desc representa una breve descripción del paquete de control. paquete. Puede elegir según sus necesidades; el prefijo "dcl" indica un paquete en tiempo de diseño, sin este prefijo indica un paquete en tiempo de ejecución, la letra "Cn" indica el tipo de compilador y el número de versión del compilador. Delphi5=D5, Delphi4=D4, CBuilder3=C3....

Tenga en cuenta que lib o std en el nombre del paquete indica si se trata de un paquete en tiempo de diseño o un paquete en tiempo de ejecución, respectivamente. Por ejemplo:

dclrbStdComPSD5.pkg: paquete de tiempo de diseño de Delphi 5

rbStdCompsD5.pkg: paquete de tiempo de ejecución de Delphi 5

4.Herramienta de formato automático de código Delphi

Aunque la mayoría de las herramientas de formato automático de código pueden ayudarlo a reorganizar el formato del programa fuente y actualizar el uso de mayúsculas en palabras e identificadores reservados, es mejor hacer esto antes de usar el control de versiones. Si ya ha usado el control de versiones, se recomienda que no lo haga. No utilice herramientas de formato automático de código fácilmente. Incluso si hay un espacio más, la herramienta de control de versiones pensará que la línea ha sido modificada, lo que provocará cambios en la gestión del programa.