Guía de estilo de Object Pascal - Por Charles Calvert
(Guía de estilo de codificación de Object Pascal - Traducido por: Tommy Tong)
Reconocemos que muchos estudios o individuos bien establecidos tienen sus propias prácticas de programación que difieren de las descritas en este artículo; sin embargo, le recomendamos encarecidamente que utilice una herramienta para convertir su código a código estilo Borland y luego enviarlo a Borland. PRoject JEDI o cualquier otro repositorio de código fuente público. No queremos obligarlo a cambiar sus hábitos, pero insistimos en que todo el código que funcione con los productos Borland siga los hábitos descritos en este artículo.
Object Pascal es un hermoso lenguaje de diseño. Una gran legibilidad es una de sus ventajas. Los estándares diseñados en este artículo mejorarán la legibilidad del código de Object Pascal. Cuando los desarrolladores sigan estos hábitos simples demostrados en este artículo, también se convertirán en estándares, lo que beneficiará a todos los desarrolladores de Delphi que utilicen un estilo de codificación unificado y legible. Los esfuerzos para hacer cumplir estos estándares aumentarán el valor del código fuente para los desarrolladores, especialmente durante las fases del ciclo de mantenimiento y depuración.
Aunque creemos y admiramos el estilo que se promueve en este artículo, no necesariamente lo respaldamos porque sea correcto en sí mismo e incorrecto en otros. Sin embargo, creemos que el estándar seguido por la gran mayoría de desarrolladores tiene su validez, por lo que seguimos apoyando y manteniendo este estilo. El cerebro humano siempre se está adaptando a los estándares y encontrando formas de organizar rápidamente patrones familiares para que su significado pueda entenderse rápida y eficientemente. Es este requisito el que establece estándares que harán que la lectura del código sea lo más fácil posible para un gran número de personas. Si nuestras pautas no le resultan familiares por primera vez, le pedimos que las siga por un tiempo y descubrirá que se acostumbrará a ellas. O, si lo prefiere, puede mantener su propio estilo y convertirlo a través de un programa que cumpla con nuestros estándares, y luego puede enviar su código a Borland u otros repositorios.
Algunos editores de texto, como Visual SlickEdit, pueden ayudarte a formatear tu código con un estilo determinado.
Un formateador gratuito desarrollado por Egbert van Nes está disponible en:
http://www.slm.wau.nl/wkao/delforexp.html
Otro programa comercial para Delphi es CrackerJax:
http://www.kineticsoftware.com/html/products.html
-------------------------------------------------- ----
1.0 Introducción
Este artículo no es un intento de definir reglas de sintaxis para el lenguaje Object Pascal. Por ejemplo: es ilegal poner el sello ";" delante de otra cosa; el compilador no permite este uso. Por eso no mostraré las reglas gramaticales en este artículo. Este artículo tiene como objetivo definir el comportamiento apropiado cuando el lenguaje ofrece opciones. Normalmente me quedo en silencio cuando sólo hay un método de control.
1.1 Antecedentes
Las pautas presentadas en este artículo se basan en parte del código fuente de Delphi. El código fuente de Delphi sigue exactamente estas pautas. Si encuentra una violación de estos principios, entonces estos principios, no el código fuente incierto, deberían ser su guía. Sin embargo, puede utilizar el código original como complemento de estos principios, al menos para ayudarle a tener una idea general de la forma de su propio código.
1.2 Gracias
Los formatos de este artículo se basan en el trabajo realizado para definir estándares de estilo para el lenguaje Java. Java no tiene influencia en las reglas para formatear el código fuente de Object Pascal, pero la documentación en el sitio web de Sun es la base de este artículo. En algunos lugares especiales, el estilo y el formato de este artículo se inspiraron en gran medida en "Una guía de estilo de codificación para la programación de Java WorkShop y Java Studio" (Achut Reddy, "Guía de codificación para Java WorkShop y Java Studio"). El artículo se puede encontrar en esta URL: http://www.sun.com/workshop/java/wp-coding
El equipo de Delphi hizo una contribución significativa para completar este artículo. De hecho, sin su ayuda, este artículo no se habría completado.
2.0 archivos fuente
El código fuente de Object Pascal se divide principalmente en archivos fuente únicos y archivos de proyecto, y todos siguen la misma convención. Los archivos de proyecto Delphi tienen una extensión .DPR. Es el archivo principal del proyecto. Cualquier archivo unitario utilizado en un proyecto tiene una extensión .PAS. Otros archivos, como archivos por lotes, archivos HTML o DLL, también pueden desempeñar un papel en el proyecto, pero este artículo solo cubre archivos de proyecto y archivos de unidad.
2.1 Nomenclatura del archivo fuente
Object Pascal admite nombres de archivos largos. Si utiliza varias palabras para formar un solo nombre, lo mejor es utilizar una letra mayúscula inicial para cada palabra: MyFile.pas. Esto se considera paréntesis o camelCase. Las extensiones deben estar en minúsculas. Por razones históricas, el código fuente de Delphi a menudo usa el patrón de nomenclatura 8:3, pero los desarrolladores no tienen que estar restringidos por las reglas anteriores y recurrir al uso del equipo de Delphi.
Si está traduciendo un archivo de encabezado C/C++, entonces el archivo Pascal que traduzca debe mantener el mismo nombre de archivo principal que el archivo de encabezado C/C++ y usar .PAS como extensión. Por ejemplo: Windows.h -> Windows.pas. Si la sintaxis de Pascal le obliga a combinar varios archivos de encabezado en un solo archivo de unidad, entonces el nombre del archivo de encabezado que contiene los otros archivos de encabezado se utilizará como nombre del nuevo archivo de unidad. Por ejemplo: Windows.h contiene el archivo WinBase.h, luego el nuevo archivo de unidad se denomina Windows.pas.
2.2 Organización del archivo fuente
Todos los archivos unitarios de Object Pascal deben contener los siguientes elementos en el siguiente orden:
Comentarios de bloqueo de derechos de autor/identidad
nombre de la unidad
segmento de interfaz
Parte de implementación
Un "fin" terminador.
Debe haber al menos una línea vacía entre cada sección.
Otros elementos deben estructurarse en el orden que considere más apropiado. Pero los derechos de autor deben aparecer al principio del archivo, luego el nombre de la unidad, luego cualquier definición condicional, directivas del compilador o declaraciones de inclusión, y luego la cláusula de usos:
{************************************************ * *****}
{ }
{Biblioteca de componentes visuales de Borland Delphi}
{ }
{ Copyright (c) 1995,98 Inprise Corporation }
{ }
{************************************************ * *****}
Botones de unidad ;
{$S-,W-,R-}
{$C PRECARGA}
interfaz
usos
Windows, Mensajes, Clases,
Controles, formularios, gráficos,
StdCtrls, ExtCtrls, CommCtrl;
Si coloca la sección de tipo antes de la sección constante, o mezcla las dos, no tiene ningún efecto.
La parte de implementación necesita escribir primero la implementación, luego la cláusula de usos y luego otras declaraciones de inclusión u otros indicadores:
implementación
usos
constantes, SysUtils, ActnList,
ListaImg;
{$R BOTONES.RES}
2.2.1 Comentarios de bloqueo de derechos de autor/identidad
Cada archivo fuente debe comenzar con un comentario de bloque que contenga información de la versión y un aviso de copyright estándar. La información de la versión puede verse así:
{************************************************ * *****}
{ }
{ Widgets en abundancia }
{ }
{ Copyright (c) 1995,98 Su empresa }
{ }
{************************************************ * *****}
El aviso de derechos de autor debe contener al menos las siguientes líneas:
Copyright (C) Año Propietario de los derechos de autor
Si es un tercero que desarrolla software para Borland, puede agregar su propio nombre al final de los derechos de autor:
{************************************************ * *****}
{ }
{Biblioteca de componentes visuales de Borland Delphi}
{ Copyright (c) 1995,99 Borland Internacional }
{ Creado por Proyecto JEDI }
{ }
{************************************************ * *****}
2.2.2 declaración de unidad
Cada archivo unitario debe tener una declaración de unidad. unidad es una palabra reservada, por lo que debe estar en minúsculas. El nombre de la unidad puede ser una mezcla de mayúsculas y minúsculas, pero debe ser el mismo que el nombre del archivo de la unidad. Por ejemplo:
unidad MiUnidad;
Entonces el nombre del archivo de la unidad debería ser MyUnit.pas. En el sistema de archivos, sirve como entrada para este archivo.
2.2.3 declaración de usos
Dentro de una unidad, las declaraciones de usos deben iniciarse con usos más pequeños. El nombre de la unidad referenciada sigue la convención de capitalización utilizada cuando se define en su propia unidad:
utilizaMiUnidad;
Cada nombre de unidad está separado del nombre de su unidad adyacente por una coma, y el último nombre de la unidad va seguido de un punto y coma:
usos
Windows, SysUtils, Clases, Gráficos, Controles, Formularios,
TipoInfo;
También es correcto agregar el nombre de la unidad a partir de la siguiente línea de usos y agregar el nombre de la unidad directamente después de los usos.
utiliza Windows, SysUtils, clases, gráficos, controles, formularios,
TipoInfo;
Puede formatear su lista de nombres de unidades para que se ajuste dentro del límite de 80 caracteres o para que tenga una línea por nombre de unidad.
2.2.4 Definiciones de clase e interfaz
Las definiciones de clases comienzan con dos espacios, seguidos del prefijo "T". El prefijo debe estar en mayúscula y cada palabra incrustada debe comenzar con mayúscula. No utilice el carácter de tabulación "Tab" en el código fuente de Object Pascal. ejemplo:
TMyClass
Siga el identificador con un espacio, luego un signo igual y luego la palabra clase, que debe estar en minúscula:
TMiClase = clase
Si su clase hereda de un antepasado, debe agregar corchetes izquierdo y derecho que contengan la clase del antepasado:
TMiClase = clase(TOobjeto)
Los indicadores de rango están a dos espacios del margen y aparecen en el siguiente orden:
TMiClase = clss(TOobjeto)
privado
proteger
público
publicado
fin;
Los datos generalmente se declaran solo en la sección privada y sus identificadores comienzan con "F". Todas estas declaraciones deben estar a 4 espacios del margen:
TMyClass = clase (TObject)
privado
FMyDate: Entero;
función ObtenerFecha: Entero;
procedimiento SetData(Valor: Entero);
público
publicado
propiedad MyData: entero leer GetData escribir SetData;
fin ;
Las interfaces siguen las mismas reglas que sus contrapartes, excepto que debes ignorar los indicadores de alcance y los datos privados, y usar la palabra interfaz en lugar de la palabra clase.
convención de nomenclatura
A excepción de las palabras reservadas y los indicadores, que están en minúsculas, todos los identificadores de Pascal deben usar el formato camelCase, es decir, la primera letra de cada identificador debe estar en mayúscula y la primera letra de las palabras incrustadas también debe estar en mayúscula. eso solo toma la primera letra.
MiIdentificador
Mi clase FTP
La principal excepción a esta regla es el caso de las traducciones de archivos de encabezado, que deben seguir las convenciones de nomenclatura de los archivos de encabezado originales. Por ejemplo:
WM_LBUTTONDOWN, no escriba wm_LButtonDown.
Excepto en el caso de las traducciones de archivos de encabezado, no utilice guiones bajos para separar palabras. Los nombres de las clases deben ser sustantivos o frases nominales. El nombre de la interfaz o clase depende del propósito obvio y del uso de la interfaz.
Buen nombre:
AddressForm, ArrayIndexOutOfBoundsException
Malos nombres:
ManageLayout //Usar frase verbal
delphi_is_new_to_me //Usar subrayado
3.1 Denominación de unidades
Ver declaración de unidad
3.2 Nomenclatura de clase/interfaz
Ver declaración de clase/interfaz
3.3 Nombres de dominio/campo
Utilice el formato camelCase. Comience con una "F" mayúscula y declare todos los datos en privado, utilizando propiedades o captadores y definidores para proporcionar acceso público. Por ejemplo: use el nombre GetSomething para nombrar una función que devuelve un campo/valor de campo interno y use SetSomething para nombrar un procedimiento que establece un campo/valor de campo.
No utilice todas las letras mayúsculas en secciones constantes a menos que sea necesario para la traducción del archivo de encabezado.
Delphi se desarrolló en California, por lo que desaconsejamos el uso de tokens a menos que sean necesarios para la traducción del archivo de encabezado.
correcto:
FMyString: cadena;
Incorrecto:
lpstrMyString: cadena;
Por supuesto, la nomenclatura húngara se conserva en la definición del tipo de enumeración:
TBitBtnKind = (bkPersonalizado, bkOK, bkCancelar, bkAyuda,
bkSí, bkNo, bkCerrar, bkAbortar, bkReintentar,
bkignore, bkTodo);
En este caso, el carácter bk se inserta antes de cada elemento de este tipo de enumeración. bk significa tipo botón.
Al considerar las convenciones de nomenclatura, evite el uso de nombres de un solo carácter, excepto para variables de tiempo cero y variables de bucle.
Evite utilizar la variable "l" (L) porque es difícil distinguirla de "1" (uno) ya sea en una impresora o en un monitor.
3.4 Denominación de métodos
La denominación de métodos también utiliza el formato camelCase. Las convenciones de nomenclatura de métodos son las mismas que las de nombrar campos no constantes, pero se pueden distinguir del contexto. La denominación de métodos debe exigir el uso de verbos o frases verbales. Por ejemplo:
//Buen método para nombrar:
Mostrar estado, dibujar círculo, agregar componente de diseño
// Denominación deficiente del método:
MouseButton //frase nominal, sin función de descripción
drawCircle //Comienza con letra minúscula
add_layout_component //Se utiliza subrayado
// Las funciones de los siguientes métodos no son lo suficientemente claras. ¿Empieza a ejecutar un servicio (mejor: StartServer) o determina si un servicio se está ejecutando (mejor: IsServerRunning)?
ServerRunning //Frase verbal, pero no un comando
Un método para obtener o establecer algunas propiedades de clase debe llamarse GetProperty o SetProperty respectivamente, donde Propiedad representa el nombre de la propiedad. Por ejemplo:
Obtener altura, establecer altura
Un método que prueba una propiedad booleana de una clase debe llamarse IsVisible, donde Visible representa el nombre de la propiedad. Por ejemplo:
EsRedimensionable, EsVisible
3.5 Nombrar variables locales
Las reglas de nomenclatura para las variables locales son las mismas que para los campos/campos, excepto que no se utiliza "F". Ver sección 3.3.
3.6 Palabras reservadas
Las palabras reservadas y los indicadores deben estar en minúsculas. Esto puede resultar un poco confuso a veces. Por ejemplo: Integer es un identificador y aparece con la primera letra en mayúscula. Las palabras reservadas de cadena están todas en minúsculas.
3.7 Declaración de tipo
Todas las declaraciones de nombres de tipos comienzan con la letra T y siguen el mismo nombre que la clase.
4.0 Uso de espacios en blanco
4.1 Líneas en blanco
Las líneas en blanco pueden mejorar la legibilidad al agrupar segmentos de código relacionados lógicamente. También se puede utilizar una línea en blanco en los siguientes lugares:
Después del bloque de comentarios de derechos de autor, la declaración del paquete (paquete) y la sección de importación (importar).
entre declaraciones de clase.
entre declaraciones de métodos.
4.2 Espacios
Object Pascal es un lenguaje muy claro y legible. Por lo general, no es necesario agregar muchos espacios para separar líneas en su código. Los siguientes artículos proporcionan algunas pautas para el uso de espacios en blanco:
4.2.2 No se deben utilizar espacios:
Entre el nombre del método y el corchete de apertura;
Antes o después del operador .(punto);
entre un operador unario y su operando;
Entre un tipo y la expresión que emite;
después del paréntesis izquierdo y antes del paréntesis derecho;
después del corchete izquierdo y antes del corchete derecho;
ante una prohibición;
Por ejemplo:
//Uso correcto:
función TMyClass.MyFunc(var Valor: Entero);
MiPuntero := @MiRegistro;
MiClase := TMiClase(MiPuntero);
MiEntero := MiArrayInteger[5];
//Uso incorrecto:
función TMyClass.MyFunc (valor var: entero);
MiPuntero := @MiRegistro;
MiClase:= TMiClase (MiPuntero);
MiEntero:= MiArrayInteger[5];
4.3 Sangría
Siempre debes aplicar una sangría de dos espacios a todos los niveles de sangría. En otras palabras, el primer nivel tiene una sangría de dos espacios, el segundo nivel tiene una sangría de cuatro espacios, el tercer nivel tiene una sangría de seis espacios... No utilice el carácter de tabulación Tab.
Por supuesto, todavía hay algunas excepciones. Las palabras reservadas como unidad, usos, tipo, interfaz, implementación, inicialización y finalización siempre están en mayúsculas. El último identificador final de la celda también es de nivel superior. En el archivo del proyecto, el programa y el inicio y el final principales también se encuentran en la cuadrícula superior. El bloque principal de inicio...final debe tener una sangría de al menos dos espacios.
4.4 Continuación
Las filas deben limitarse a 80 columnas. Las filas con más de 80 columnas deben dividirse en varias filas consecutivas. Todas las líneas siguientes deben seguir la primera línea de esta declaración y tener una sangría de dos caracteres de espacio.
Por ejemplo:
//correcto:
función CreateWindowEx(dwExStyle: DWord;
lpClassName: PChar; lpWindowName: PChar;
dwStyle: DWORD X, Y, nAncho, nAlto: Entero;
hWndParent: HWND; hMenú: HMENU; hInstancia: HINST;
lpParam: Puntero ): HWND;
si ((X = Y) o (Y = X) o
(Z = P) o (F = J) entonces
comenzar
S := J;
fin ;
No ajuste líneas entre un parámetro y su tipo a menos que la lista esté separada por comas, en cuyo caso ajuste antes del último parámetro para que el nombre del tipo comience en la línea siguiente. No debe haber ningún espacio entre los dos puntos y su variable, y debe haber un espacio entre los dos puntos y el nombre del tipo.
//correcto:
procedimiento Foo(Param1: Entero; Param2: Entero);
//error:
procedimiento Foo( Parámetro:Entero; Param2:Entero);
Una línea posterior no debe comenzar con un operador binario. Evite cortar una línea donde normalmente no aparecen espacios en blanco, como entre el nombre de un método y su corchete de apertura, o entre el nombre de una matriz y su corchete de apertura. Si debe romper líneas en la situación anterior, rompa la línea después del corchete de apertura o del corchete de apertura. No pongas comenzar en la misma línea que otro código.
Por ejemplo:
//error:
mientras (LongExpression1 o LongExpression2 ) comienzan
//Hacer algo
//Hacer algo más;
fin ;
//correcto
mientras que (LongExpression1 o longExpression2) lo hacen
comenzar
//Hacer algo
//Hacer algo más;
fin ;
si (LongExpressiong1) o
(Expresiónlarga2) o
(LongExpression3) entonces
5.0 Comentarios
El lenguaje Object Pascal admite dos tipos de comentarios: comentarios de bloque y de una sola línea. A continuación se muestran algunas pautas de uso de anotaciones:
·Es útil colocar comentarios en la parte superior de la unidad explicando el propósito de la misma.
·Es útil colocar comentarios antes de las declaraciones de clase.
·Es útil establecer anotaciones antes de las declaraciones de métodos.
·Evita comentarios con significados obvios
i := i + 1; //Agrega uno a i
·Recuerde que los comentarios que se malinterpretan fácilmente son más dañinos que ningún comentario.
·Evita poner información en comentarios que parezca no válida
·Evite incrustar asteriscos u otros símbolos tipográficos en los bordes de los comentarios.
·Los comentarios de hora cero, es decir, los comentarios que deben cambiarse o eliminarse, deben marcarse con "???:" delante de ellos, para que sean fáciles de encontrar. Conceptualmente, todos los comentarios de tiempo cero deben eliminarse antes de que se lance el programa.
// ???: Cambia esto para llamar a Ordenar cuando esté arreglado
Lista.MiOrdenación;
5.1 Bloquear comentarios
Object Pascal admite dos tipos de comentarios de bloque. Los más utilizados son los comentarios encerrados entre llaves {}. El equipo de Delphi mantuvo los comentarios lo más pocos y simples posible. Por ejemplo: debes evitar el uso de asteriscos para crear patrones o líneas en tus comentarios. En su lugar, utilice espacios para separar sus comentarios, tal como lo haría en un documento de procesamiento de textos. Las palabras de su comentario deben comenzar en la misma línea que la primera llave, como en el siguiente extracto de DsgnIntf.pas:
{ TPropertyEditor
Edita una propiedad de un componente, o una lista de componentes,
seleccionado en el Inspector de objetos.
El editor se crea según el tipo de
propiedad que se está editando según lo determinado por los tipos
registrado por...
etc...
Obtener valor Xxx
Obtiene el valor de la primera propiedad del
Propiedades propiedad Llama a la apropiada.
Método TProperty GetXxxValue para recuperar el
valor.
SetXxxValue Establece el valor de todas las propiedades.
en la propiedad Propiedades. Llama al apropiado.
Métodos TProperty SetXxxxValue para establecer el valor.
Los comentarios en bloque se utilizan a menudo en comentarios de derechos de autor. También se utiliza para comentar algunas líneas de código.
Un comentario de bloque que explique el propósito del método debe ir precedido de la declaración del método.
Por ejemplo:
// CORRECTO
{ TMiObjeto.MiMétodo
Esta rutina le permite ejecutar código }
procedimiento TMyObject.MyMethod;
comenzar
fin;
// INCORRECTO
procedimiento TMyObject.MyMethod;
{************************************************ * ****
TMyObject.MiMétodo
Esta rutina le permite ejecutar código.
************************************************** * *****}
comenzar
fin;
El segundo tipo de comentario de bloque contiene dos caracteres, paréntesis y un asterisco: (* *). A esto a veces se le llama comentario entre corchetes de estrella. Estas anotaciones generalmente solo son útiles durante el desarrollo del código y su principal beneficio es que permiten que las anotaciones anidadas tengan menos de dos niveles de profundidad. Object Pascal no admite el mismo tipo de anidamiento de comentarios, por lo que en realidad solo hay un nivel de anidamiento: llaves dentro de llaves de estrella, o llaves de estrella dentro de llaves. Las anotaciones Pascal estándar de otros tipos dentro de anotaciones de este tipo se ignorarán siempre que no las anide. Por lo tanto, puedes usar esta sintaxis para comentar un gran bloque de código que contenga código y comentarios:
(* procedimiento TForm1.Button1Click(Remitente: TObject);
comenzar
Hacer esto; // Iniciar el proceso
Hacer eso; // Continuar la iteración
{ Necesitamos una forma de informar errores aquí, tal vez usando
¿Un intento finalmente de bloquear?
CallMoreCode; // Finaliza el proceso
fin ; *)
En este caso, se comenta todo el método Button1Click, incluidos los subcomentarios que contenga.
5.2 Comentarios de una sola línea
Un comentario de una sola línea consta de un carácter de comentario // y su texto inicial, con un espacio entre el texto y el carácter de comentario. Si los comentarios de una sola línea están en líneas diferentes a las del código, deben tener el mismo nivel de sangría que el código. Puede utilizar varios comentarios de una sola línea para formar un comentario grande.
Se requiere una línea en blanco antes de un comentario de una sola línea o un grupo de comentarios, a menos que sea la primera línea de un bloque. Si se utilizan comentarios para varias declaraciones, los comentarios y los grupos de comentarios deben ir seguidos de una línea en blanco. Si el comentario sólo explica la afirmación en la línea que le sigue, no es necesario que vaya seguido de una línea en blanco.
Por ejemplo:
//Abrir la base de datos
Tabla1.Abierta;
Los comentarios de una sola línea también pueden seguir a las declaraciones de código que explican. A veces, estos comentarios se denominan comentarios de seguimiento. Debe haber al menos un espacio entre ellos y el código. Si aparecen varios comentarios de seguimiento simultáneamente en un bloque de código, estos comentarios deben estar alineados.
Por ejemplo:
si ( no esVisible) entonces
Salir; // nada que hacer
Inc(StrLength); // reserva espacio para terminador nulo
Evite rastrear comentarios en cada línea de código ejecutable. Generalmente es mejor limitar el uso de comentarios, o incluso dejarlos vacíos, entre los bloques de inicio y fin de un método o función. Pueden aparecer comentarios largos en los comentarios de bloque antes de la definición de métodos y funciones.
amable
6.1 Organización de clases
La organización de los órganos de clase deberá seguir el siguiente orden:
·Declaración de dominio/campo
·Declaración del método
·Definición de atributos
Los dominios/campos, propiedades y métodos deben estar indexados alfabéticamente por sus nombres.
6.1.1 Niveles de acceso
Excepto el código generado por el IDE, los designadores de alcance para las clases deben estar en el siguiente orden:
·declaración privada
· declaración de protección
·declaración pública
·Declaración publicada
En Object Pascal, los miembros de la clase tienen cuatro niveles de acceso: publicado, público, protegido y privado, en orden decreciente de capacidades de acceso. El nivel de acceso predeterminado está publicado. Generalmente, a un miembro se le debe asignar el nivel de acceso más bajo que sea más apropiado para él. Por ejemplo: los miembros a los que solo pueden acceder otras clases en la misma unidad deben declararse privados. Al mismo tiempo, declarar miembros con niveles de acceso bajos también le da al compilador la oportunidad de mejorar la optimización. Por supuesto, por otro lado, el uso de niveles de acceso bajos dificulta la ampliación de las subclases. Si hay razones para creer que una clase será subclasificada en algún momento en el futuro, entonces aquellos miembros que la subclase debe heredar y extender deben declararse como protegidos. Las propiedades utilizadas para acceder a datos privados también pueden proporcionar esta protección.
Debe prohibir el acceso público a los datos. Los datos generalmente se declaran en la sección privada, y cualquier acceso público a ellos debe realizarse a través de los métodos o propiedades GetXXX, SetXXX.
6.1.8 Declaración del constructor
Los métodos deben ordenarse por índice alfabético. Es correcto colocar los constructores y destructores al principio de la sección pública o ordenarlos alfabéticamente.
Si hay varios constructores o utiliza varios constructores con el mismo nombre, deben organizarse de acuerdo con la lista de parámetros, con el que tiene menos parámetros delante del que tiene más parámetros. Esto significa que si hay un constructor sin parámetros, este debe aparecer primero. Para mantener la mejor compatibilidad con C++Builder, la lista de parámetros del constructor debe ser única. C++ no llama a un constructor según su nombre, por lo que la única forma de distinguir varios constructores es a través de su lista de argumentos.
6.2 Declaración del método
Si es posible, las declaraciones de métodos deben aparecer en una sola línea.
Por ejemplo:
Ejemplos:
procedimiento ImageUpdate(Image img, infoflags: Integer,
x: entero, y: entero, w: entero, h: entero)
Interfaz 7.0
Una declaración de interfaz tiene la misma forma que una declaración de clase:
NombreDeInterfaz = interfaz ([ interfaz heredada ])
InterfazCuerpo
fin ;
Las declaraciones de interfaz deben tener una sangría de dos espacios, los cuerpos de la interfaz de cuatro espacios y los caracteres finales de dos espacios.
No hay campos/campos en la declaración de interfaz. Pero los atributos pueden aparecer.
Todos los métodos de interfaz son inherentemente públicos y abstractos, y no es necesario incluir dichas palabras clave en la declaración de la interfaz.
A menos que se indique lo contrario, las declaraciones de interfaz tienen el mismo estilo que las declaraciones del mismo tipo.
7.1 Organización del cuerpo de interfaz
El cuerpo de la interfaz se puede organizar en el siguiente orden:
·Declaración del método de interfaz
·Declaración de atributos de interfaz
Los métodos y propiedades de la interfaz se declaran con el mismo estilo que las clases.
Declaración 8.0
Una declaración es una línea o líneas de código que terminan con un sello. Una declaración única tiene un solo número de prohibición y una declaración compuesta tiene varios nombres de prohibición.
//Esta es una sola declaración:
A := B;
//Esta es una declaración compuesta:
comenzar
B:= C;
A := B;
fin ;
8.0.1 Declaración única
Si es necesario ajustar una sola declaración, es necesario sangrar dos espacios con respecto a la línea anterior.
//Por ejemplo:
MiValor :=
MiValor + (AlgunaDeclaraciónMuyLarga / OtraDeclaraciónLarga);
8.1.1 Declaraciones de asignación y expresión
Puede haber como máximo una declaración por línea.
Por ejemplo:
a := b + c; Inc(Contar); //Error
a := b + c //Correcto
Inc(Contar); //Correcto
8.1.2 Declaración de variables locales
Las variables locales también usan el formato camelCase. No use el líder "F", que está reservado para campos/campos en declaraciones de clase.
Por ejemplo:
var
MisDatos: Entero;
MiCadena: cadena ;
Puedes declarar múltiples variables del mismo tipo en la misma línea:
var
ArraySize, ArrayCount: entero;
Este hábito de declaración no se recomienda en declaraciones de clase.
8.1.3 Declaración de matriz
Es común poner siempre un espacio antes del corchete de apertura y después del corchete de cierre:
tipo
TMyArray = matriz [0..100] de Char;
8.2.3 si declaración
La declaración if debe aparecer en al menos dos líneas:
Por ejemplo:
//error:
si A = B entonces HazAlgo;
//correcto
si A = B entonces
hacer algo;
Si es una declaración if compuesta, debería haber una nueva línea para cada delimitador:
//error:
si A = B entonces comienza
hacer algo;
hacer algo más;
fin si no comenzar
Haz esto;
Haz eso;
fin ;
//correcto
si A = B entonces
comenzar
hacer algo;
hacer algo más;
fin
demás
comenzar
Haz esto;
Haz eso;
fin ;
Se pueden adoptar algunas variaciones de lo siguiente:
//correcto
si condición entonces
comenzar
Haz esto;
fin de otra manera
comenzar
Haz eso;
fin ;
//correcto
si condición entonces
comenzar
Haz esto;
fin
demás
hacer algo;
//correcto
si condición entonces
comenzar
Haz esto;
fin de otra manera
hacer algo;
// Puede que no le importe el siguiente método, pero es digno de elogio:
si condición entonces
Haz esto
de lo contrario , haz eso;
8.2.4 para declaración
Ejemplo:
// INCORRECTO
para i: = 0 a 10 comenzar
hacer algo;
hacer algo más;
fin ;
// CORRECTO
para i := 0 a 10 hacer
comenzar
hacer algo;
hacer algo más;
fin ;
8.2.5 declaración mientras
Ejemplo:
// INCORRECTO
mientras que x < ; j comienzan
hacer algo;
hacer algo más;
fin ;
// CORRECTO
mientras x < j hacer
comenzar
hacer algo;
hacer algo más;
fin ;
8.2.6 repetir hasta declaración
Ejemplo:
// CORRECTO
repetir
x := j;
j := ActualizarValor;
hasta j = 25;
8.2.7 declaración de caso
Ejemplo:
// CORRECTO
Control de casos . Alineación de
alIzquierda, alNinguno: NuevoRango := Max(NuevoRango, Posición);
bien: Inc(AlignMargin, Control.Width);
fin ;
// CORRECTO
caso x de
CSSinicio:
comenzar
j := ActualizarValor;
fin ;
csBegin: x := j;
csTiempo de salida:
comenzar
j := x;
x := ActualizarValor;
fin ;
fin ;
// CORRECTO
caso Código de desplazamiento de
SB_LINEUP, SB_LINEDOWN:
comenzar
Incr := FIncrement div FLineDiv;
FinalIncr := FIncrement mod FLineDiv;
Contar := FLineDiv;
fin ;
SB_PAGEUP, SB_PAGEDOWN:
comenzar
Incr := FPageIncremento;
FinalIncr := Incr mod FPageDiv;
Incr := Incr div FPageDiv;
Contar := FPageDiv;
fin ;
demás
Contar := 0;
Incr := 0;
Incrfinal:= 0;
fin ;
8.2.8 declaración de prueba
//Correcto
intentar
intentar
EnumThreadWindows(CurrentThreadID, @Disable, 0);
Resultado := TaskWindowList;
excepto
EnableTaskWindows(TaskWindowList);
aumentar ;
fin ;
finalmente
TaskWindowList := GuardarWindowList;
TaskActiveWindow:= GuardarActiveWindow;
fin ;
Blog del autor: http://blog.csdn.net/sailerbai/