Los estándares de codificación proporcionan principalmente al equipo de desarrollo una guía de programación para que los desarrolladores de proyectos tengan un formato consistente a seguir al programar. De esta manera, el código escrito por cada programador del equipo de desarrollo puede ser entendido por otros, mejorando así la capacidad de mantenimiento del código, haciendo que un conjunto de software escrito por varias personas sea como si estuviera escrito por una sola persona, lo que facilita el código. para entender. Esto requiere que todos utilicen un estilo de codificación coherente. Bueno, la razón por la cual es un cliché introducir estos estándares es porque cuando nuevos desarrolladores se unen al equipo de desarrollo del proyecto, es posible que algunos no estén familiarizados con los estándares de codificación de Delphi. Estos estándares se presentarán aquí en las siguientes categorías: 1. Reglas generales de formato de código fuente 2. Procedimientos y funciones 3. Nomenclatura de archivos, formularios y módulos de datos 4. Nomenclatura de paquetes y componentes Reglas generales de formato de código fuente La sangría es cada nivel Hay dos espacios entre ellos. 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.). Márgenes 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. Los corchetes no tienen 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. CallPRocedure(Parameters); // ¡Incorrecto! CallProcedure (Parameters); // ¡Correcto! Palabras reservadas y palabras clave Objeto Las palabras reservadas y las palabras clave del lenguaje Pascal siempre están completamente en minúsculas. La declaración start...endbegin debe estar en su propia línea. Por ejemplo, la primera línea a continuación es incorrecta, pero la segunda línea es correcta: for i:=0 to 10 do startStatement end// Incorrecto, comenzar está en la misma línea que for i:=0 to 10 do //Correcto ! comenzar en Un caso especial de esta regla en startStatementend en otra línea es cuando comenzar es parte de una declaración else. Por ejemplo: if Condition thenbeginStatement endelse startStatement; 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. Declaración (1) La situación más probable de la declaración if_then_else debe colocarse en la cláusula entonces, y la situación improbable 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. En el código fuente, los paréntesis se utilizan sólo cuando realmente son necesarios. Por ejemplo: si (I=42) entonces // Incorrecto, los paréntesis son redundantes si (I=42) o (J=42) entonces // Correcto, se deben usar paréntesis Si hay múltiples condiciones para probar en la declaración if, Debes organizarlos 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. 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 debe construirse así: if Condición1 y Condición2 y Condición3 entonces(2) declaración case_else Las constantes para cada caso en la declaración case deben ordenarse en orden numérico o alfabético orden. 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 una declaración de caso solo se usa para casos predeterminados o detección de errores. (3) La declaración while recomienda no utilizar el proceso de salida 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) Declaración for Si se determina el número de bucles, se debe utilizar la declaración for en lugar de la declaración while. (5) declaración repetida La declaración repetida es similar a un bucle while y sigue las mismas reglas. (6) declaración with 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 y Record2, estas situaciones pueden confundir fácilmente a los programadores y dificultar la depuración. Manejo estructurado de excepciones 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. (1) Uso de try...finally Siempre que sea posible, cada asignación de recursos debe coincidir con la estructura try...finally. Por ejemplo: //El siguiente código puede causar errores SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;//Una solución segura para el recurso anterior la asignación es: SomeClass1: = TSomeClass Create;trySomeClass2: = TSomeClass Create;try{hacer algo de código}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) Uso de try...except Si desea realizar algunas tareas cuando se produce una excepción, puede utilizar 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. (3) Se desaconseja el uso de try...except...else usando try...except con una cláusula else, porque esto bloqueará todas las excepciones, incluidas las excepciones que no está preparado para manejar.