Spécifications de codage Delphi Auteur : Tulipsys Date de mise à jour : 16 décembre 2003 Contenu 1. Conventions générales (dénomination - indentation et espaces - marges - casse - commentaires) 2. Déclaration (début...fin déclaration-si déclaration-cas déclaration-pour déclaration-pendant déclaration-répétition déclaration-avec déclaration-instruction de gestion des exceptions) 3. Procédures et fonctions (dénomination et format-paramètres formels-variables-type-types personnalisés) 4. Le but de la formulation de normes de codage liées à l'orientation objet (dénomination de classe et implémentation de méthode format-champ-propriété-méthode) est de permettre à un groupe de programmeurs de générer du code dans le même style, afin qu'une équipe puisse former et maintenir un certain style. Si cet objectif est atteint, l'ensemble des fichiers du projet semblera avoir été écrit par un programmeur. La bonté est amusante, mais l'avantage est que le code de chaque programmeur est facile à comprendre par les autres, ce qui améliorera considérablement la maintenabilité du code et réduira donc les coûts de maintenance. C’est une situation idéale pour n’importe quelle équipe. Pour les individus, choisir ou auto-générer une norme de codage et adhérer à cette norme peut également produire de bons résultats. C’est d’ailleurs un objectif très tentant, mais pas trop difficile à atteindre. Chaque langage de programmation a ses propres normes de codage. Les normes de codage peuvent être considérées comme un résumé de l'expérience. Bien entendu, nous devons également apprendre des normes d'autres langages de programmation. Il est donc très important d’apprendre des autres. Deuxièmement, l'utilisation de normes de codage vise à simplifier le travail des programmeurs. Le sens de la « simplification » n'est pas de réduire la quantité de code (au contraire, suivre les normes plusieurs fois apportera plus de code), mais de réduire la quantité de code du programmeur. travail pour maintenir la quantité de code. La programmation est un travail très complexe. Il est intimidant de gérer diverses relations, et celles-ci sont inextricablement liées. Les programmeurs devraient consacrer la majeure partie de leur énergie à gérer les relations et éviter de perdre du temps sur des questions trop détaillées. S'il peut comprendre l'idée et la structure du programme en un coup d'œil, un plan de maintenance sera rapidement élaboré. De plus, la norme de codage doit être une norme très conviviale à laquelle vous pouvez vous référer et modifier, mais elle doit être facile à utiliser. Mais dans un groupe, assurez-vous que tout le monde utilise les mêmes normes. La programmation est un travail très flexible. Ce n'est qu'avec une réflexion et une application flexibles que de bons résultats peuvent être obtenus. De plus, l'utilisation de spécifications vise en grande partie à réduire la charge de mémoire des programmeurs. La capacité de réflexion humaine est extrêmement excellente, mais la mémoire est très faible. Nous sommes confrontés à des ordinateurs toute la journée, et la chose la plus importante qu'ils veulent nous aider à faire est la mémoire. Par conséquent, l’un de nos objectifs est de maximiser les avantages de réflexion des programmeurs. Enfin, les outils de programmation ont une grande influence sur les normes de codage, et cette influence vient du style de programmation du développeur. Également basé sur le C++, nous n'utiliserons pas exactement les mêmes spécifications de codage dans Microsoft Visual C++ et Borland C++ Builder. Microsoft et Borland ont des styles différents et bien distincts. En tant qu'utilisateurs, nous pouvons apporter des modifications sur cette base, mais il y a des limites. En fait, lorsque nous faisons des choix concernant les fournisseurs et les outils de développement, nous déterminons également notre style futur. 1. Conventions générales 1.1 Dénomination Le principe de base de la dénomination est que le nom doit exprimer clairement la fonction des données. Object Pascal prend en charge les noms de fichiers longs. Les noms doivent utiliser des verbes, des noms ou une combinaison des deux. Vous ne devez pas utiliser de mots réservés et de mots-clés définis dans Delphi, et essayez de ne pas utiliser de mots réservés et de mots-clés définis dans d'autres langages. Essayez d'utiliser des mots complets et évitez les abréviations, les préfixes et suffixes, les traits de soulignement ou autres symboles. La nomenclature hongroise n'est pas recommandée. Les conventions de dénomination sont utilisées pour garantir la lisibilité des noms. Les normes de dénomination représentées par la nomenclature hongroise ont développé de nombreux préfixes et suffixes pour indiquer le type, la portée ou d'autres attributs divers des données. Dans Delphi, vous pouvez certainement utiliser cette méthode, mais ce n’est pas une méthode recommandée. L'une des raisons est que ce type de convention de dénomination entraîne trop de tâches de mémoire supplémentaires, et une autre raison est déterminée par les caractéristiques de Delphi lui-même. La vérification de type obligatoire de Delphi surveillera automatiquement l'utilisation de toutes les variables, nous n'avons donc besoin que d'y prêter un peu d'attention (faites attention à la capitalisation des mots) sans avoir à ajouter laborieusement divers préfixes. En outre, l’examen des données doit être basé sur leur signification plutôt que sur leur type ou leur portée, et une attention particulière doit être portée à la structure du programme, aux relations logiques et aux idées de conception. Ainsi, dans Delphi, il vous suffit d'utiliser une combinaison complète de mots pour nommer, de ne rien considérer d'autre et, bien sûr, vous devez le garder aussi concis que possible. Dans certaines instructions (telles que les boucles for), nous devons utiliser plusieurs entiers comme variables de comptage. Ici, vous pouvez simplement utiliser les trois lettres i, j et k comme noms de variables. C’est une habitude qui a été développée et conservée dans le langage Fortran, et elle s’est avérée très utile et facile à comprendre. Bien sûr, nous aurions de meilleurs résultats en utilisant un nom plus significatif, tel que : MyCounter. D'une manière générale, les trois lettres i, j et k sont tout à fait suffisantes, sinon davantage de processus ou de fonctions devraient être divisés. Voici quelques exemples : 1. SongsList //Indique qu'il s'agit d'une liste de chansons. Song utilise le pluriel pour indiquer qu'il y a plus d'une chanson. 2. SetCarColor //Indique qu'il s'agit d'une fonction permettant de définir la couleur de. la voiture. Si une classe TCar est définie, alors SetColor est utilisé dans la classe en tant que membre de fonction pour définir la couleur de la voiture. Faites également attention à la dénomination des variables booléennes. Le nom d'une variable booléenne doit clairement indiquer la signification de True et False. Par exemple, pour une variable qui enregistre si un fichier existe, il est préférable d’utiliser IsFileExisted plutôt que FileExisted. Enfin, ne nommez jamais une variable globale Temp ou Tmp, mais elle est toujours autorisée au sein d'une procédure ou d'une fonction. En fait, cette règle suscite une certaine controverse. Certaines normes de codage sont plus strictes et sont absolument interdites, même dans les procédures ou les fonctions. Cependant, cette dénomination est souvent très pratique, notamment pour les procédures ou les fonctions. Si elle est utilisée comme variable globale, il est probable qu'il y ait une instruction d'affectation avec des types incompatibles. Bien que le compilateur vous apporte beaucoup d'aide pour le moment, il est difficile d'éviter l'apparition de petites erreurs. En résumé, suivre cette règle produira de meilleurs résultats, mais rien ne doit être strictement respecté si nécessaire. 1.2 Indentation et espaces Deux espaces doivent être indentés entre chaque niveau. Cela rendra le programme clair et bien organisé. N'utilisez jamais de caractères de tabulation, car leur largeur est difficile à maintenir cohérente avec les différents paramètres et applications, mais ne vous attendez pas à ce que votre programme soit affiché uniquement dans Delphi. Faites également attention à l'utilisation de l'éditeur. Si vous choisissez uniquement Delphi, il n'y a pas de problème ; si vous utilisez également un traitement de texte tel que Word, veillez à utiliser des polices appropriées pour vous assurer que la largeur de chaque lettre et symbole est adaptée. le même. . Lorsque vous imprimez avec un traitement de texte tel que Word, vous devez également faire attention à la sélection des polices. L'utilisation d'espaces vise également à garder le programme propre et à permettre aux programmeurs de comprendre rapidement la structure du programme. Voici quelques spécifications et exemples correspondants : 1. Il devrait y avoir un espace entre chaque mot. Par exemple : pour TMyClass = class(TObject)2． Il doit y avoir un espace autour de "=", "<>", ">=" et "<=" ; il doit y avoir un espace à droite de ":=" et ":", mais pas à gauche. Par exemple : si a = b alors a:= b ; Il doit y avoir un espace entre les mots et mots-clés réservés et le symbole de gauche, mais pas entre le symbole de droite. Par exemple : PRocedure ShowMessage ; surcharge ;4. Utilisation de parenthèses : dans la définition et l'appel des procédures et des fonctions, aucun espace ne doit être laissé entre les parenthèses et les mots et symboles externes ; aucun espace ne doit être laissé entre les parenthèses et les mots internes. Dans le jugement conditionnel de l'instruction if, des espaces doivent être utilisés entre les mots réservés tels que et et ou. Par exemple : function Exchange(a: integer; b: integer); if (a = b) and ((a = c) or (a = d)) then … end;1.3 margin L'éditeur Delphi est à environ 81e à partir de la droite. est une ligne sombre laissée au niveau du caractère. En fait, sous l'interface par défaut de Delphi, lorsque la résolution est de 800*600, la fenêtre agrandie sera affichée 4 lettres à gauche de la ligne sombre. Par conséquent, n'écrivez pas de code source en dehors de la ligne sombre, ce qui signifie que chaque ligne ne doit pas dépasser 80 caractères, espaces de début et du milieu compris. Si l'instruction est trop longue, le saut de ligne est terminé et le saut de ligne doit être indenté de deux caractères. Ceci est également facile à imprimer et les parties au-delà de la ligne sombre ne seront pas imprimées dans Delphi. Si vous utilisez un logiciel de traitement de texte tel que Word pour imprimer un programme Delphi, la partie excédentaire sera déplacée au début de la ligne suivante, rendant le programme imprimé difficile à lire. Par conséquent, essayez de faire tous les ajustements lors de l’écriture du code et ne laissez pas ce genre de travail à l’impression. Lorsque vous enveloppez des lignes, veillez à maintenir la lisibilité du programme et essayez de conserver la partie complète. Par exemple, si la fonction est trop longue, enveloppez une description complète du paramètre au lieu de simplement la déclaration du type de données. Les deux premières façons d'écrire ci-dessous sont correctes et les méthodes d'écriture suivantes sont incorrectes : function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //Corriger la fonction AdditonFiveInputNumber; (a : entier ;b : entier ;c : entier ;d : entier ;e : entier) : entier //Fonction correcte ; AdditonFiveInputNumber(a: entier; b: entier; c: entier; d: entier; e: entier): entier; //Fonction d'erreur AdditonFiveInputNumber(a: entier; b: entier; c: entier; d: entier;e: entier ): entier; //Fonction d'erreur AdditonFiveInputNumber(a: entier; b: entier; c: entier; d: entier;e: entier): entier; //Erreur 1.4 La première lettre de chaque mot du nom personnalisé doit être en majuscule et en minuscule, et les autres lettres doivent être en minuscules. Les mots et mots-clés réservés Delphi doivent tous être en minuscules. La méthode d'écriture des fonctions prédéfinies Delphi est la même que la méthode d'écriture des noms personnalisés. Les types de données de base dans Delphi doivent être en minuscules et les deux premières lettres des types de classes étendues doivent être en majuscules (la première lettre d'un type de classe est "T"). Voici quelques exemples : 1. Nom personnalisé : MyFavouriteSong, CarList ; 2. Mots réservés : if (a = b) and ((a = c) or (a = d)) then … end ; (« Tout va bien »);4. Type de classe d'extension Delphi : MyStrings = TStrings.Create;1.5 Commentaires Delphi prend en charge deux types de commentaires : les commentaires en bloc ({}) et les commentaires sur une seule ligne (//). Le but des commentaires est d'expliquer les idées de conception du programme et d'aider les programmeurs à comprendre le plus tôt possible les idées du programme écrit il y a deux ans ou même hier. Il s'agit en fait de résoudre le problème de la mémoire. Le cerveau ne doit pas être surutilisé en tant que mémoire. Ne comptez jamais trop sur le cerveau dans la programmation, mais utilisez autant que possible des mots. Par conséquent, les commentaires sont un aspect très important dans les langages de programmation, même si de nombreuses personnes (surtout les débutants, y compris un nombre considérable de programmeurs) n'y voient pas d'inconvénient et écrivent rarement des commentaires. Une autre application des commentaires est en phase de débogage du programme. Par exemple, s'il y a deux instructions et que vous ne savez pas à l'avance laquelle est la meilleure, vous devez tester : mettre "//" avant une instruction (c'est-à-dire modifier). l'instruction à commenter), exécutez une autre instruction, puis faites l'inverse, nous pouvons facilement faire le choix. S'il s'agit d'un groupe d'instructions, utilisez des commentaires en bloc, mais veillez à placer "{" et "}" à des endroits bien visibles, par exemple sur des lignes supérieures et inférieures distinctes. Voici quelques principes d'utilisation : 1. Dans la plupart des cas, il est nécessaire de placer des commentaires devant les variables et types personnalisés. 2. Dans la plupart des cas, il est nécessaire de placer un commentaire en tête du fichier unité. Ici, le commentaire doit inclure : le nom du fichier, la date de création, la date de modification, l'auteur, l'auteur de la modification et la description nécessaire. 3. Les commentaires doivent être significatifs, n'utilisez pas de commentaires inutiles. Par exemple : while i < 8 dobegin … i:= i + 1; //Add one to iend; le commentaire "//Add one to i" n'a aucun sens ici, bien sûr, cela ne signifie pas une simple déclaration (semblable à : i : = i + 1) aucun commentaire n'est nécessaire. Étant donné que des déclarations simples jouent souvent un rôle très important, si cette déclaration suscite des questions ou est difficile à comprendre, alors sa fonction doit être marquée. 4. N'essayez pas de créer des monogrammes dans les commentaires, sauf si vous pensez que c'est absolument nécessaire. Parce qu'il est très difficile de modifier l'annotation tout en gardant le motif intact et beau. . 5. Pour distinguer les commentaires temporaires des commentaires permanents, vous pouvez utiliser votre méthode pour placer des symboles spéciaux dans les commentaires. L’avantage est qu’il est facile à trouver. 6. Les modifications apportées aux déclarations sont mappées aux commentaires correspondants. 7. Il doit y avoir un écart évident entre les commentaires et le code, afin que vous puissiez distinguer d'un coup d'œil ce qui est une instruction et lequel est un commentaire. Vous pouvez placer des commentaires sur la ligne avant ou après la ligne de code, ou laisser au moins deux espaces immédiatement après le code, mais ne mettez pas le code après le commentaire lorsque le code et le commentaire sont sur la même ligne. ne pas mettre le code après le commentaire. Les commentaires sont placés au milieu du code.