Especificaciones de codificación Delphi Autor: Tulipsys Fecha de actualización: 16 de diciembre de 2003 Contenido 1. Convenciones generales (nombramiento - sangría y espacios - márgenes - mayúsculas y minúsculas - comentarios) 2. Declaración (comenzar... finalizar declaración-si declaración-caso declaración-para declaración-mientras declaración-repetir declaración-con declaración-excepción manejo declaración) 3. Procedimientos y funciones (nombramiento y formato-parámetros formales-variables-tipo-tipos personalizados) 4. El propósito de formular estándares de codificación relacionados con la orientación a objetos (nombramiento de clases e implementación de formato-campo-método-propiedad-método) es permitir que un grupo de programadores genere código del mismo estilo, de modo que un equipo pueda formar y mantener un cierto estilo. Si se logra este objetivo, todos los archivos del proyecto parecerán escritos por un programador. Dios es divertido, pero la ventaja es que el código de cada programador es fácil de entender para los demás, lo que mejorará en gran medida la capacidad de mantenimiento del código y, por lo tanto, reducirá los costos de mantenimiento. Esta es una situación ideal para cualquier equipo. Para los individuos, elegir o autogenerar una norma de codificación y adherirse a ella también puede producir buenos resultados. Por cierto, este es un objetivo muy tentador, pero no demasiado difícil de lograr. Cada lenguaje de programación tiene sus propios estándares de codificación. Se puede decir que los estándares de codificación son un resumen de la experiencia. Por supuesto, también debemos aprender de los estándares de otros lenguajes de programación. Por eso, es muy importante aprender de los demás. En segundo lugar, el uso de estándares de codificación es para simplificar el trabajo de los programadores. El significado de "simplificación" no es reducir la cantidad de código (por el contrario, muchas veces seguir los estándares generará más código), sino reducir la cantidad de código del programador. mano de obra para mantener la cantidad del código. La programación es un trabajo muy complejo. Es desalentador lidiar con varias relaciones y existen vínculos inextricables entre varias relaciones. Los programadores deberían dedicar la mayor parte de su energía a ocuparse de las relaciones y evitar perder el tiempo en cuestiones demasiado detalladas. Si puede comprender la idea y la estructura del programa de un vistazo, se formará rápidamente un plan de mantenimiento. Además, el estándar de codificación debe ser un estándar muy fácil de usar que pueda consultarse y modificarse, pero debe ser fácil de usar. Pero en un grupo, asegúrese de que todos utilicen los mismos estándares. La programación es un trabajo muy flexible. Sólo con un pensamiento flexible y una aplicación flexible se pueden obtener buenos resultados. Además, el uso de especificaciones tiene como objetivo en gran medida reducir la carga de memoria de los programadores. La capacidad de pensamiento humano es extremadamente excelente, pero la memoria es muy pobre. Nos enfrentamos a las computadoras todo el día y lo más importante que quieren ayudarnos es la memoria. Por lo tanto, uno de nuestros objetivos es maximizar las ventajas de pensamiento de los programadores. Finalmente, las herramientas de programación tienen una gran influencia en los estándares de codificación, y esta influencia proviene del estilo de programación del desarrollador. También basado en C++, no usaremos exactamente las mismas especificaciones de codificación en Microsoft Visual C++ y Borland C++ Builder. Microsoft y Borland tienen estilos diferentes y muy distintos. Como usuarios, podemos realizar cambios en función de esto, pero existen límites. De hecho, cuando elegimos proveedores y herramientas de desarrollo, también determinamos nuestro estilo futuro. 1. Convenciones generales 1.1 Denominación El principio básico de la denominación es que el nombre debe expresar claramente la función de los datos. Object Pascal admite nombres de archivos largos. Los nombres deben utilizar verbos, sustantivos o una combinación de ambos. No debe utilizar palabras reservadas ni palabras clave definidas en Delphi, y trate de no utilizar palabras reservadas y palabras clave definidas en otros idiomas. Intente utilizar palabras completas y evite abreviaturas, prefijos y sufijos, guiones bajos u otros símbolos. No se recomienda la nomenclatura húngara. Se utilizan convenciones de nomenclatura para garantizar la legibilidad de los nombres. Los estándares de denominación representados por la nomenclatura húngara han desarrollado muchos prefijos y sufijos para indicar el tipo, alcance u otros atributos diversos de los datos. En Delphi, ciertamente puede utilizar este método, pero no es un método recomendado. Una razón es que este tipo de convención de nomenclatura conlleva demasiadas tareas de memoria adicionales, y otra razón está determinada por las características del propio Delphi. La verificación de tipos obligatoria de Delphi monitoreará automáticamente el uso de todas las variables, por lo que solo necesitamos prestar un poco de atención (preste atención a las mayúsculas de las palabras) sin tener que agregar laboriosamente varios prefijos. Además, la consideración de los datos debe basarse en el significado más que en el tipo o alcance, y se debe prestar atención a la estructura del programa, las relaciones lógicas y las ideas de diseño. Entonces, en Delphi solo necesitas usar una combinación completa de palabras para nombrar, no considerar nada más y, por supuesto, debes mantenerlo lo más conciso posible. En algunas declaraciones (como los bucles for) necesitamos usar varios números enteros como variables de conteo. Aquí puede utilizar simplemente las tres letras i, j y k como nombres de variables. Este es un hábito que se desarrolló y retuvo en el lenguaje Fortran y ha demostrado ser muy útil y fácil de entender. Por supuesto, obtendríamos mejores resultados si usáramos un nombre más significativo, como por ejemplo: MiContador. En términos generales, las tres letras i, j y k son completamente suficientes; de lo contrario, se deberían dividir más procesos o funciones. A continuación se muestran algunos ejemplos: 1. SongsList // Indica que se trata de una lista de canciones. El número plural de canción indica que hay más de una canción. 2. SetCarColor // Indica que se trata de una función para establecer el color. el automóvil. Si se define una clase TCar, entonces SetColor se usa en la clase como miembro de la función para establecer el color del automóvil. También preste atención a la denominación de las variables booleanas. El nombre de una variable booleana debe indicar claramente el significado de Verdadero y Falso. Por ejemplo, para una variable que registra si un archivo existe, usar IsFileExisted es mejor que usar FileExisted. Finalmente, nunca nombre una variable global Temp o Tmp, pero aún así está permitida dentro de un procedimiento o función. De hecho, existe un poco de controversia sobre esta regla. Algunos estándares de codificación son más estrictos. Dicha denominación está absolutamente prohibida, incluso en procedimientos o funciones. Sin embargo, muchas veces esta denominación resulta realmente conveniente, sobre todo para procedimientos o funciones. Si se usa como variable global, es probable que haya una declaración de asignación que no coincida con el tipo. Aunque el compilador le brindará mucha ayuda en este momento, es difícil evitar la aparición de pequeños errores. . En resumen, seguir esta regla producirá mejores resultados, pero no se debe cumplir nada estrictamente si es necesario. 1.2 Sangría y espacios Se deben sangrar dos espacios entre cada nivel. Esto hará que el programa sea claro y esté bien organizado. Nunca use caracteres de tabulación, porque es difícil mantener el ancho de los caracteres de tabulación consistentes con diferentes configuraciones y aplicaciones, pero no espere que su programa solo se vea en Delphi. También preste atención al uso del editor. Si solo elige Delphi, entonces no hay problema si también usa un procesador de texto como Word, preste atención al uso de fuentes adecuadas para garantizar el ancho de cada letra y símbolo; es lo mismo. Al imprimir con un procesador de texto como Word, también debes prestar atención a la selección de fuentes. El uso de espacios también sirve para mantener el programa limpio y permitir a los programadores comprender rápidamente la estructura del programa. Las siguientes son algunas especificaciones y ejemplos correspondientes: 1. Debe haber un espacio entre cada palabra. Por ejemplo: para TMyClass = clase(TObject)2． Debe haber un espacio alrededor de "=", "<>", ">=" y "<="; debe haber un espacio a la derecha de ":=" y ":", pero no a la izquierda. Por ejemplo: si a = b entonces a:= b; a: entero; Debe haber un espacio entre las palabras reservadas y las palabras clave y el símbolo de la izquierda, pero ningún espacio entre ellas y el símbolo de la derecha. Por ejemplo: Procedimiento Mostrar mensaje; sobrecarga;4. Uso de corchetes: En la definición y llamada de procedimientos y funciones no se deben dejar espacios entre corchetes y palabras externas y símbolos; no se deben dejar espacios entre corchetes y palabras internas; En el juicio condicional de la declaración if, se deben usar espacios entre palabras reservadas como y y o. Por ejemplo: función Exchange(a: entero; b: entero); si (a = b) y ((a = c) o (a = d)) entonces… fin; 1.3 margen El editor Delphi está aproximadamente en el puesto 81 desde la derecha. es una línea oscura que queda en el carácter. De hecho, bajo la interfaz predeterminada de Delphi, cuando la resolución es 800*600, la ventana maximizada se mostrará 4 letras a la izquierda de la línea oscura. Por lo tanto, no escriba el código fuente fuera de la línea oscura, lo que significa que cada línea no debe exceder los 80 caracteres, incluidos los espacios iniciales y medios. Si la declaración es demasiado larga, el salto de línea se completa y el salto de línea debe tener una sangría de dos caracteres. Esto también es fácil de imprimir y las partes más allá de la línea oscura no se imprimirán en Delphi. Si utiliza un software de procesamiento de textos como Word para imprimir un programa Delphi, la parte sobrante se moverá al principio de la siguiente línea, lo que dificultará la lectura del programa impreso. Por lo tanto, intente realizar todos los ajustes mientras escribe el código y no deje este tipo de trabajo para imprimir. Al ajustar líneas, preste atención a mantener la legibilidad del programa e intente conservar la parte completa. Como ejemplo, si la función es demasiado larga, incluya una descripción completa del parámetro en lugar de solo la declaración del tipo de datos. Las dos primeras formas de escribir a continuación son correctas y las siguientes formas de escribir son incorrectas: function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //Función correcta AdditonFiveInputNumber; (a: entero;b: entero;c: entero;d: entero;e: entero): entero: //Función correcta; AdditonFiveInputNumber(a: entero; b: entero; c: entero; d: entero; e: entero): entero; //Función de error AdditonFiveInputNumber(a: entero; b: entero; c: entero; d: entero;e: entero ): entero; //Función de error AdditonFiveInputNumber(a: entero; b: entero; c: entero; d: entero;e: entero): entero; //Error 1.4 La primera letra de cada palabra en el nombre personalizado debe estar en mayúscula y minúscula, y las demás letras deben estar en minúscula. Las palabras reservadas y las palabras clave de Delphi deben estar todas en minúsculas. El método de escritura de las funciones predefinidas de Delphi es el mismo que el método de escritura de nombres personalizados. Los tipos de datos básicos en Delphi deben estar en minúsculas y las dos primeras letras de los tipos de clases extendidas deben estar en mayúscula (la primera letra de un tipo de clase es "T"). A continuación se muestran algunos ejemplos: 1. Nombre personalizado: MyFavouriteSong, CarList; 2. Palabras reservadas: if (a = b) y ((a = c) o (a = d)) entonces… fin. ("Todo bien");4. Tipo de clase de extensión de Delphi: MyStrings = TStrings.Create;1.5 Comentarios Delphi admite dos tipos de comentarios: comentarios en bloque ({}) y comentarios de una sola línea (//). El propósito de los comentarios es explicar las ideas de diseño del programa y ayudar a los programadores a comprender las ideas del programa escrito hace dos años o incluso ayer lo antes posible. En realidad, esto es para resolver el problema de la memoria. No se debe abusar del cerebro como memoria. Nunca confíes demasiado en el cerebro al programar, sino usa palabras tanto como sea posible. Por tanto, los comentarios son un aspecto muy importante en los lenguajes de programación, aunque a muchas personas (especialmente a los principiantes, incluido un número considerable de programadores) esto no les importa y rara vez escriben comentarios. Otra aplicación de los comentarios se encuentra en la etapa de depuración del programa. Por ejemplo, si hay dos declaraciones y no sabe cuál es mejor de antemano, debe probar: coloque "//" antes de una declaración (es decir, cambie). la declaración para comentar), ejecutar otra declaración y luego hacer lo contrario, podemos tomar la decisión fácilmente. Si se trata de un grupo de declaraciones, utilice comentarios en bloque, pero asegúrese de colocar "{" y "}" en posiciones destacadas, como en líneas superiores e inferiores separadas. Los siguientes son algunos principios de uso: 1. En la mayoría de los casos, es necesario colocar comentarios delante de las variables y tipos personalizados. 2. En la mayoría de los casos, es necesario colocar un comentario en la parte superior del archivo de la unidad. Aquí, el comentario debe incluir: nombre del archivo, fecha de creación, fecha de modificación, autor, autor de la modificación y descripción necesaria. 3. Los comentarios deben ser significativos, no utilice comentarios inútiles. Por ejemplo: while i < 8 dobegin … i:= i + 1; //Agregar uno a iend; el comentario "//Agregar uno a i" no tiene sentido aquí, por supuesto, no significa una declaración simple (similar a: i : = i + 1) no se necesita ningún comentario. Debido a que las declaraciones simples a menudo juegan un papel muy importante, si esta declaración hace que la gente cuestione o es difícil de entender, entonces se debe marcar la función de esta declaración. 4. No intentes crear monogramas en los comentarios a menos que creas que es absolutamente necesario. Porque es muy difícil modificar la anotación manteniendo el patrón intacto y hermoso. . 5. Para distinguir los comentarios temporales de los permanentes, puede utilizar su método para colocar símbolos especiales en los comentarios. La ventaja de esto es que es fácil de encontrar. 6. Los cambios en las declaraciones se asignan a los comentarios correspondientes. 7. Debe haber una brecha clara entre los comentarios y el código, de modo que pueda saber de un vistazo cuál es una declaración y cuál es un comentario. Puede colocar comentarios en la línea antes o después de la línea de código, o dejar al menos dos espacios inmediatamente después del código. Sin embargo, cuando el código y los comentarios estén en la misma línea, no coloque el código después del comentario. no coloque el código después del comentario. Los comentarios se colocan en el medio del código.