Les normes de codage fournissent principalement à l’équipe de développement une ligne directrice de programmation afin que les développeurs de projets disposent d’un format cohérent à suivre lors de la programmation. De cette façon, le code écrit par chaque programmeur de l'équipe de développement peut être compris par d'autres, améliorant ainsi la maintenabilité du code, créant un ensemble de logiciels écrits par plusieurs personnes comme s'il avait été écrit par une seule personne, rendant le code plus facile comprendre. Cela nécessite que chacun utilise un style de codage cohérent. Ainsi, la raison pour laquelle il est cliché d'introduire ces normes est que lorsque de nouveaux développeurs rejoignent l'équipe de développement du projet, certains ne sont peut-être pas familiers avec les normes de codage de Delphi. Ces normes seront présentées ici dans les catégories suivantes : 1. Règles générales de formatage du code source 2. Procédures et fonctions 3. Dénomination des fichiers, formulaires et modules de données 4. Dénomination des packages et des composants Règles générales de formatage du code source L'indentation est pour chaque niveau Il existe deux espaces entre eux. Ne placez pas de caractères de tabulation dans le code source. En effet, la largeur du caractère de tabulation varie en fonction des différents paramètres et utilitaires de gestion de code (impression, documentation, contrôle de version, etc.). Marges Les marges sont définies sur 80 caractères. Le code source ne dépasse généralement pas la marge en écrivant un mot, mais cette règle est plus souple. Dans la mesure du possible, les instructions de plus d'une ligne doivent être entourées de virgules ou d'opérateurs. Après un saut de ligne, il doit être mis en retrait de deux caractères. Les crochets n'ont pas d'espace entre le crochet ouvrant et le caractère suivant. De même, il n’y a pas d’espace entre le crochet fermant et le caractère précédent. L'exemple suivant montre les espaces corrects et incorrects. CallPRocedure(Parameters); // Faux ! CallProcedure (Parameters); // Correct ! Objet Les mots et mots-clés réservés du langage Pascal sont toujours entièrement en minuscules. L'instruction start...endbegin doit figurer sur une ligne distincte. Par exemple, la première ligne ci-dessous est fausse, mais la deuxième ligne est correcte : for i:=0 to 10 do beginStatement end// Wrong, start est sur la même ligne que for i:=0 to 10 do //Correct ! start in Un cas particulier de cette règle dans beginStatementend sur une autre ligne est lorsque start fait partie d'une instruction else. Par exemple : si Condition thenbeginStatement endelsebeginStatement ; l'instruction endend se trouve toujours sur une ligne distincte. Lorsque le début ne fait pas partie d'une instruction else, l'instruction de fin correspondante est indentée du même montant que l'instruction de début. Instruction (1) La situation la plus probable de l'instruction if_then_else doit être placée dans la clause then, et la situation improbable doit être placée dans la clause else. Pour éviter de nombreuses instructions if, utilisez plutôt des instructions case. S'il y a plus de 5 niveaux, n'utilisez pas d'instructions if. Veuillez plutôt utiliser une méthode plus claire. N'utilisez pas de parenthèses supplémentaires dans les instructions if. Dans le code source, les parenthèses ne sont utilisées que lorsqu'elles sont vraiment nécessaires. Par exemple : if (I=42) then // Faux, les parenthèses sont redondantes if (I=42) ou (J=42) then // Correct, les parenthèses doivent être utilisées S'il y a plusieurs conditions à tester dans l'instruction if, vous devez organiser de droite à gauche par ordre de complexité informatique. Cela permet au code de tirer pleinement parti de la logique d'estimation des courts-circuits du compilateur. Si Condition1 est plus rapide que Condition2 et Condition2 est plus rapide que Condition3, l'instruction if doit être construite comme ceci : if Condition1 et Condition2 et Condition3 then(2) instruction case_else Les constantes de chaque cas dans l'instruction case doivent être classées par ordre numérique ou alphabétique. commande. L'instruction d'action pour chaque situation doit être courte et ne doit généralement pas dépasser 4 à 5 lignes de code. Si l'action est trop complexe, le code doit être placé dans une procédure ou une fonction distincte. La clause else d'une instruction case n'est utilisée que pour les cas par défaut ou la détection d'erreurs. (3) L'instruction while recommande de ne pas utiliser le processus de sortie pour quitter la boucle while. Si nécessaire, une condition de boucle doit être utilisée pour quitter la boucle. Tout le code qui initialise la boucle while doit être situé avant l'entrée while et ne doit pas être séparé par des instructions non pertinentes. Tout travail auxiliaire pour l'entreprise doit être effectué immédiatement après le cycle. (4) instruction for Si le nombre de boucles est déterminé, l'instruction for doit être utilisée à la place de l'instruction while. (5) instruction répétition L'instruction répétition est similaire à une boucle while et suit les mêmes règles. (6) instruction with L'instruction with doit être utilisée avec prudence. Évitez d'abuser des instructions with, en particulier lorsque vous utilisez plusieurs objets ou enregistrements dans une instruction with. Par exemple : avec Record1, Record2, ces situations peuvent facilement dérouter les programmeurs et rendre le débogage difficile. Structured Exception HandlingLa gestion des exceptions est principalement utilisée pour corriger les erreurs et protéger les ressources. Cela signifie que partout où des ressources sont allouées, il faut essayer... enfin de garantir que les ressources soient libérées. Cependant, des exceptions sont faites si des ressources sont allouées/libérées dans la partie initiale/finale de l'unité ou dans le constructeur/destructeur de l'objet. (1) Utilisation de try...finally Dans la mesure du possible, chaque allocation de ressources doit correspondre à la structure try...finally. Par exemple : //Le code suivant peut provoquer des erreurs SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;//Une solution sûre pour la ressource ci-dessus l'allocation est : SomeClass1 : = TSomeClass Create ;trySomeClass2 : = TSomeClass Create ;try{faire du code}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) Utilisation de try...sauf Si vous souhaitez effectuer certaines tâches lorsqu'une exception se produit, vous pouvez utiliser try...sauf. Habituellement, il n'est pas nécessaire d'utiliser try...sauf pour simplement afficher un message d'erreur, car l'objet application peut le faire automatiquement en fonction du contexte. Si vous souhaitez activer la gestion des exceptions par défaut dans la clause, vous pouvez déclencher à nouveau l'exception. (3) L'utilisation de try...sauf...else est déconseillée en cas d'utilisation de try...sauf avec une clause else, car cela bloquera toutes les exceptions, y compris les exceptions que vous n'êtes pas prêt à gérer.