Avertissement : ce qui suit liste des conseils écrits au début des années 2000. Conséquemment, bien que l'essence de ce qui suit demeure raisonnable, je vous recommande de lire le tout d'un oeil aiguisé et de prendre soin de discriminer ce qui a bien vieilli de ce qui a un peu souffert.
Remarques préliminaires
Nous utiliserons des noms à consonance francophone. Libre à vous d'angliciser chacun si telle est la pratique de votre entreprise, vous souvenant ce faisant que la structure des phrases anglaises diffère de celles énoncées en français (p. ex. : DEFAULT_NOTE au lieu de NOTE_DEFAUT).
Règle générale, les différences entre les nomenclatures dues à des différences de langue sont moindres qu'on ne le croirait, les termes techniques tendant à se ressembler d'une langue à l'autre, sous l'influence de l'anglais.
L'orthographe joue un rôle important dans le vécu informatique. Veillez à sauver temps et argent à votre firme, et prenez soin d'utiliser l'orthographe la plus juste possible, et d'insister auprès de vos employé(e)s pour qu'ils/ elles en fassent autant.
Peu importe la significativité de la nomenclature employée, il ne faut en aucun cas oublier à quel point l'emploi systématique de commentaires, au moins à la déclaration de chaque variable, chaque constante, chaque sous-programme, etc. est essentiel, surtout pour la maintenance à long terme du code d'un projet informatique.
D'autres réflexions sur la question de la nomenclature dans les programmes sont disponibles ici.
Pour un texte sur le bon usage des constantes et sur la nomenclature bien choisie, voir ces quelques textes de Peter Vogel :
On demande souvent (en fait, toujours!) aux gens devant mettre la main à la pâte lors du développement informatique d'utiliser des noms significatifs pour leurs variables, constantes, sous-programmes, types, classes, instances, méthodes, modules, etc.
L'emploi systématique de commentaires judicieux, la rigueur quant à la nomenclature, et le respect des standards en place sont trois des éléments fondamentaux menant à une autodocumentation des programmes.
Certains doivent appliquer ces standards; il s'agit surtout des gens devant programmer, tester ou aider à la documentation d'un logiciel. D'autres doivent veiller à établir des standards, à les faire respecter, à vérifier occasionnellement leur application, et (surtout, quoiqu'on en pense) à les vendre à leurs collègues et employés.
Vous risquez fort de vous retrouver dans le second groupe. Cela dit, vous devrez connaître autant (sinon plus!) que vos développeurs les normes à appliquer dans votre entreprise, et les moteurs derrière les décisions menant à l'application de ces normes.
Tout chambarder?
Certaines firmes ont des standards particuliers et précis, alors que d'autres prennent une approche plus relaxe, mais donnent quand même des standards généraux auxquels les équipes de développement devront se conformer.
L'objectif derrière ce document est d'aider à la réflexion et de présenter quelques points de vue communs ou répandus. Il est clair que, si vous devez vous intégrer à une firme existante, les standards déjà en place seront probablement pour vous ceux à privilégier d'abord et avant tout; à moins que votre tâche ne soit de refondre les standards en place, il est probable que vous soyez d'abord appelé(e) à comprendre et à assimiler les façons de faire locales d'abord, puis (peut-être un jour) à les réexaminer si elles ne vous semblent plus adéquates.
Sur le plan programmatique, la norme usuelle veut que les constantes symboliques portent des noms écrits entièrement en majuscules. Ceci tient principalement d'une tradition liée aux usages en pseudocode, qui cousine celle des langages de Niklaus Wirth, et de l'époque des macros du langage C. Notez que cette pratique est remise en question par certains, dont Jonathan Wakely dans http://accu.org/var/uploads/journals/Overload121.pdf aux pages 13-14.
En pseudocode, où on omet de typer les données dans le but de se détacher de la technique pour réfléchir en termes algorithmiques, l'emploi de lexèmes entièrement en majuscules simplifie l'identification de ces données invariantes et importantes que sont les constantes.
Les constantes ont, toujours selon la tradition, une valeur « brûlée » à la compilation. Un compilateur peut alors utiliser le caractère invariant et littéral de ces données pour optimiser certaines partie d'un programme, par exemple, ou pour réserver l'espace associé à des tableaux.
Avec l'approche objet, où une instance doit être construite et détruite mais peut quand même être constante, et où des constantes locales à un sous-programme peuvent parfois être spécifiées sans que leur valeur ne soit connue à la compilation, la définition de bas niveau d'une constante s'élargit un peu.
Certaines constantes ont des noms à caractère historique. On pense par exemple à PI, qui est traditionnellement associé à l'usage fait en mathématiques de la lettre grecque du même nom; à NULL pour un pointeur vers l'adresse 0 en langage C (mais pas en C++); ou à des constantes comme TPS ou TVQ qui, contrairement à PI, ont une valeur précise délimitée dans le temps et sujette à des changements occasionnels.
Les constantes systèmes, connues telles quelles des langages de programmation (plutôt que définies dans une bibliothèque), sont parfois en minuscules. On pense ici au null de Java (pour identifier une référence non instanciée) ou aux true et false de Java et de C++, qui sont les littéraux acceptables pour une donnée booléenne, pour ne donner que des exemples communs.
Remarquez que ces « constantes » ont fréquemment en commun le fait... de ne pas tant être des constantes symboliques que des littéraux d'un type donné. Un autre objectif visé par cet emploi des minuscules est de réduire les risques de conflits avec les noms utilisés dans les programmes écrits à l'aide de ces langages.
D'autres constantes servent à des fins d'énumération, quand la cardinalité des énumérables est finie (et, idéalement, assez brève) et quand chaque élément énumérable peut se faire attribuer, en propre, un nom significatif. On peut penser ici à des constantes pour les jours de la semaine (LUNDI à DIMANCHE, par exemple), les mois de l'année, les signes du zodiaque, etc.
On séparera par des caractères de soulignement les mots distincts qui composeront un nom de constante (p. ex: JOURS_FERIES); c'est là une coutume à peu près universelle.
L'emploi d'une stratégie OO permet de compartimenter les noms de manière à limiter le recours à de tels préfixes.
En effet, si une classe Note contient des constantes MIN et MAX, et s'il est clair qu'il s'agit des valeurs minimum et maximum pour une Note, alors la classe peut parfois jouer le rôle de qualificateur. Après tout, Note::MAX est aussi clair que NOTE_MAX.
On visera habituellement à ce que les constantes portent un nom qui dénote bien ce qu'elles représentent. Pour les constantes de spécification de taille ou de quantité, par exemple celles exprimant la taille d'une tableau, on préfixera généralement le nom de la constante par un vocable comme MAX ou NB. Pensez à NB_ELEVES pour les élèves d'une classe, ou à MAX_ELEMENTS pour une collection de taille bornée.
Dénoter une valeur maximale ou minimale, comme dans le cas où on voudrait spécifier les bornes de validité d'un type de données, l'usage veut qu'on utilise plutôt MAX et MIN comme suffixes. Si on veut indiquer la note minimale et la note maximale acceptables pour un type Note, on pensera souvent à NOTE_MIN et NOTE_MAX.
Dans le même ordre d'idées, on choisira souvent d'identifier la valeur par défaut pour un type de données par une constante dont le nom est suffixé par DEFAUT. Dans le cas d'une Note, on reconnaîtra immédiatement NOTE_DEFAUT comme la valeur par défaut utilisée (ou à utiliser) pour ce type.
Lorsque des constantes peuvent être groupées, comme par exemple lorsqu'on liste des constantes qui serviront à la spécification du texte apparaissant sur des contrôles pour une interface personne/ machine, on voudra généralement les regrouper.
Regrouper ces constantes se fera à la fois logiquement (placer dans un même module les constantes vouées à une même tâche ou à une même structure de données) et par une forme d'homophonie.
On pourrait suffixer toutes les constantes d'un groupe de la même manière (par exemple, par MENU_MNE pour des mnémoniques de menus), mais on tendra généralement plutôt à regrouper les constantes à l'aide de préfixes. Ceci facilite la recherche et les tris par ordre alphabétique, entre autres choses.
L'approche objet nous donne aussi un outil de classement intéressant pour le regroupement de constantes à proximité logique les unes des autres: les classes et les membres de classe.
Cette stratégie est prise à plein par Java, et un peu moins par C++ (à cause du lourd héritage du langage C, sans doute, et par souci d'interopérabilité avec des langages de programmation qui ne serait pas orientés objet), quoique la tendance C++ ISO vers les espaces nommés a implicitement procédé à un regroupement logique de toute entité présente dans toute unité de code C++, qu'on en profite pleinement ou non.
Selon cette stratégie, donc, on spécifiera des classes ayant entre autres pour rôle de regrouper des constantes de classe publiques de vocation connexe et, le plus souvent, des méthodes de classe servant à convertir des données, valider des données, et autrement manipuler à la fois les constantes en question et les variables qui leur sont apparentées.
Exemple concret : la classe Integer de Java
Par exemple, Java propose la classe Integer, dont chaque instance représente (sous forme objet) un entier (un int du langage Java). Avoir une version objet de chaque type primitif est nécessaire, en Java, pour un ensemble de raisons techniques.
Dans la classe Integer, on trouve :
On y trouve aussi des constructeurs et des méthodes d'instance, bien sûr. Cela n'est par contre pas une condition d'application de la stratégie de regroupement dont nous discutons ici: on pourrait imaginer sans peine une classe ne servant qu'à exposer, de manière publique, un ensemble de constantes logiquement associées, et qui ne serait pas vouée à être instanciée.
Les méthodes de classe sont l'alternative Java aux fonctions globales de C++; les constantes groupées par classe y sont l'alternative plus localisée aux constantes globales de C++.
De son côté, C++ a choisi de regrouper d'abord les données qui étaient globales avant la norme ISO dans des espaces nommés, sans empêcher qui que ce soit d'utiliser plutôt des classes à des fins de regroupement.
Toute donnée, classe, fonction, constante, etc. n'étant pas spécifiquement dans une espace nommé est, en C++ ISO, dans l'espace nommé anonyme (drôle de nom, soit, mais correct tout de même). Ainsi, la fonction main() porte le nom effectif ::main() (le préfixe :: sans nom de namespace signifie que main() est dans l'espace anonyme).
Les problèmes informatiques ayant tendance à s'étendre sur des problèmes vastes et où apparaît la nécessité de gérer une masse d'identificateurs (constantes, variables, etc.) très importante, on évitera le plus possible les noms de variables d'une seule lettre ou les monosyllabiques, et dans les rares cas où on les utilisera, on fera en sorte que l'usage soit de portée très locale.
Les cas documentés de problèmes importants abondent : des gens qui oublient de déclarer un compteur nommé i et qui ne s'en aperçoivent pas, du fait que leur programme compile – parce qu'il existe une variable globale nommée i – et qui, par inadvertance, modifient ainsi un compteur global utilisé dans un autre sous-programme, ce qui introduit un bogue majeur et très, très difficile à identifier.
Dans les cas où la tradition les motive (on pense immédiatement au cas des boucles for avec un compteur d'itérations comme i, j ou k), on s'assurera de ne jamais utiliser des variables globales portant un nom non-significatif.
On suggère généralement aussi d'utiliser des noms qui seront familiers aux gens susceptibles d'oeuvrer auprès du même code source, dans l'immédiat comme dans le futur envisageable. On voudra éviter l'emploi de terminologie échappant au commun des gens appelés à collaborer à un module, à moins bien sûr que ladite terminologie ne soit de nature technique et qu'elle soit intimement liée au projet en développement.
Cela dit, même dans un tel cas, il ne faut pas négliger l'importance des commentaires accompagnant la déclaration, qui devront donner une chance aux gens appelés à contribuer au projet de saisir le rôle de la variable malgré un bagage a priori différent.
De manière complémentaire à la mathématique, où l'humain est penseur et acteur principal de la recherche d'une solution, d'une stratégie ou d'une démonstration, l'informatique vise souvent les tâches et problèmes où l'automatisation doit primer sur l'intervention humaine, incluant les situations où le volume de données ou la taille du problème dépassent les capacités des humains.
On remarque aussi que les mathématiciennes et les mathématiciens sont souvent appelés à résoudre des problèmes d'ordre général, s'appliquant à une classe de situations très large, et à amener des solutions opérant de fait à un niveau d'abstraction élevé si on le compare aux situations réelles dans lesquelles elles seront, concrètement, appliquées.
La signification des noms de variables est alors souvent détachée des contextes d'application, ce qui est raisonnable et compréhensible. Les problèmes auxquels s'attaquent l'informaticienne et l'informaticien sont parfois de cet ordre, mais peuvent plus souvent être liées à des situations pour lesquelles des variables aux noms monosyllabiques ou écrites d'un ou deux caractères seulement serait moins approprié. On recommande donc fortement, en informatique, de faire usage pour une variable de noms significatifs à son rôle dans le contexte de son utilisation
Les variables tendent à désigner des états; de ce fait, on espère d'une variable que son nom donne une idée immédiate de son rôle dans le contexte où elle est destinée à servir. On évitera de donner à une variable le nom d'un verbe d'action, et même (si possible) d'un verbe d'état. En effet, les verbes ayant un sens plus dynamique, on les réservera généralement pour les noms de sous-programmes, ou pour les foncteurs.
Des exceptions sont possibles, comme celui d'une variable booléenne nommée DoitPoursuivre ou Poursuivre et servant à contrôler la poursuite de l'itération d'une répétitive. Cela dit, on pourrait y aller par la négative et utiliser plutôt la négation d'une variable nommée Fini ou Termine (Terminé si votre langage accepte les caractères accentués; Done ou Completed en anglais) pour signifier précisément la même chose
On évitera bien sûr les noms de variables écrits strictement en majuscules, fuyant les ambiguïtés avec les conventions en place pour les constantes. Si un programme devait calculer une approximation de π plutôt que le la prendre pour acquis, utilisant ainsi une variable plutôt qu'une constante, on s'attendrait à voir cette variable nommée Pi et non pas PI.
Plusieurs firmes suggèrent que, même dans les langages où les lettres majuscules et les minuscules sont considérées comme des symboles différents[8], on évite d'utiliser deux variables portant exactement le même nom aux majuscules et aux minuscules près (cette suggestion s'étend au couple variable/ constante aussi, de manière évidente).
De l'emploi du caractère de soulignement
L'emploi du caractère de soulignement est chose débattue dans certains cercles. Les uns aiment, les autres détestent. Certains séparent tous les mots compris dans un même nom par des soulignements, d'autres ne les utilisent qu'à certains endroits, et d'autres encore ne les utilisent jamais.
Ma recommandation personnelle serait de ne pas en abuser. En prenant pour acquis que les constantes soient rédigées à l'aide de lettres majuscules seulement, le recours àdes caractères de soulignement y est chose raisonnable du fait qu'on ne peut alors pas se fier aux lettres majuscules pour marquer le début des mots.
L'utilisation du soulignement pour des raisons techniques est aussi recommandable (p. ex. : pour marquer la séparation entre un préfixe et un nom, comme lorsqu'on applique une règle telle que préfixer les noms d'attributs par m ou par un m_), du fait que cela accroît la lisibilité du code et y facilite le repérage pour les lectrices et les lecteurs.
Dans le cas de noms de variables, de classes, de sous-programmes ou autres, une majuscule pour marquer le début d'un mot suffit habituellement pour la plupart des gens et la plupart des usages.
L'emploi de noms significatifs doit être balancé par un souci de clarté et de concision. Entre CompteurDuNombreDEleves et CompteurEleves (ou, si la pratique locale le permet, CptEleves), on ne remarque pas de réelle perte de sens – il est clair dans chaque cas qu'on utilise cette variable pour compter ou énumérer des élèves. Les formules brèves entraînent ici une présentation plus claire pour le code pris dans son ensemble, et sont plus directement accessibles à la lecture.
Remarquez, par opposition, que les noms Cpt_E ou i ne véhiculent pas du tout un sens aussi clair et complet.
La modération et l'équilibre sont des qualités recherchées ici pour supporter les efforts de clarté, pas pour aller à leur encontre. Si plusieurs langages supportent des noms d'identificateurs d'une longueur maximale de 127 ou de 255 caractères, on voudra idéalement se limiter à moins de 30 caractères.
On le voit avec l'exemple du compteur d'élèves ci-dessus: il arrive fréquemment qu'un nom de variable soit en fait un composé de plusieurs noms. On essaiera d'utiliser, pour nommer ces variables, un standard qui mette en relief les noms qui les composent. Ceci peut signifier séparer les mots par des caractères de soulignement, utiliser une majuscule pour débuter chaque mot, ou une combinaison des deux.
Selon les standards locaux, on utilisera parfois une majuscule pour débuter un nom de variable, et parfois une minuscule. L'important ici est (a) de respecter les standards locaux, et (b) qu'il existe ou non des standards locaux, d'être constant(e) et conséquent(e) dans la démarche choisie.
Certaines firmes recommandent aussi de définir des standards pour les variables dites jetables (en anglais : les Throwaway Variables). On verra souvent des variables préfixées par le terme dummy, par exemple, ou par spare pour des variables servant à réserver de l'espace en vue d'ajouts à un système dont la taille ne doit pas, pour différentes raisons, varier trop souvent.
Lorsque le besoin de variables globales survient, ce qui survient à l'occasion pour des raisons techniques, plusieurs ont pris l'habitude de préfixer leur nom par g_, s'inspirant ainsi des standards de facto en vigueur pour les noms d'attributs. Les variables globales étant à éviter le plus possible, on vise à les repérer avec aisance dans un programme.
Conséquemment, on évitera pour les variables locales les préfixes comme s_, m_ ou g_, du fait que plusieurs les réservent pour spécifier des attributs de classe, d'instance ou des variables globales. Ceci que votre firme fasse partie ou non des utilisateurs de ce standard – l'idée est de réduire les risques de conflit et d'ambiguïté.
Dans une approche objet, on vise à décourager l'accès direct aux attributs d'une instance. L'emploi de la spécification privé va bien sûr en ce sens; il se trouve que dans le passé pas si lointain, certaines expériences orientées objet à vocation commerciale ne supportaient pas, à l'origine, l'encapsulation stricte à même le langage.
Pour motiver les programmeuses et les programmeurs à éviter l'accès direct aux attributs, les gens se sont alors mis à les préfixer systématiquement de caractères de soulignement. Un, puis deux, parfois même trois, toujours dans l'optique où on voulait mettre en relief que les accesseurs et les manipulateurs, eux, portaient des noms stables et effectuaient les bonnes opérations de la bonne façon. Une forme d'encapsulation par la force brute, disons.
Historiquement, les présentation de C++ utilisent les vocables member variable et member function pour parler respectivement d'un attribut ou d'une méthode; ceci pour faciliter la transition vers C++ des programmeurs structurés, surtout ceux – nombreux – qui sont d'abord habitués au langage C.
Avec la généralisation du support à l'encapsulation stricte à même les langages de programmation, on a développé l'habitude de préfixer les noms d'attributs d'instance de m ou de m_, au sens de membre, et cela même si le mot membre s'applique tout autant aux méthodes qu'aux attributs (on ne préfixe pas les méthodes de cette façon).
Certains ont pris l'habitude de préfixer les membres de classe en Java et en C++ d'un s_, bien qu'il s'agisse là d'une habitude de travail beaucoup moins répandue. La plupart des attributs de classe tendent en effet à être des constantes, pour lesquelles un préfixe du genre n'a pas vraiment de pertinence.
Cette pratique, relativement rare pour l'instant, a un côté assez agaçant : le terme static pour un membre de classe est un terme technique qui n'évoque pas clairement le caractère membre de classe de ce qui lui est associé. Le préfixe s_ est donc très lié à une culture locale, et qui est difficilement transférable sans perte de sens.
Pour le reste, on essaiera de lier la nomenclature des attributs aux conventions de nomenclature en vogue dans l'entreprise.
Le premier critère de bonne nomenclature pour un sous-programme est de s'assurer que le nom soit un reflet fidèle de la tâche que ce sous-programme doit réaliser. Ceci peut sembler évident, mais un examen sommaire des pratiques en entreprise montre que la plupart des sous-programmes existants sont déficients en ce sens.
Les divergences entre nom et vocation pour un sous-programme tiennent surtout de deux facteurs, chacun important à sa façon :
On essaiera d'utiliser des verbes d'action pour débuter la plupart des noms de sous-programmes, ces entités étant pour la plupart des unités de code actives, quoiqu'on puisse imaginer des fonctions dont le nom est bien choisi mais débute par un verbe d'état (par exemple la fonction EstPair(n) qui retourne vrai si et seulement si n est un entier pair).
On a longtemps choisi des fonctions portant des préfixes similaires pour faciliter la documentation et l'organisation du code. Avec les langages orientés objet, on tend à ne plus se préoccuper autant de considérations du genre, du fait que, spontanément, les méthodes soient groupées par objet.
Lorsqu'un projet est réfléchi selon l'approche objet mais à l'aide de langages qui, eux, ne sont pas des langages orientés objet, on fera souvent attention de préfixer les fonctions destinées à devenir des méthodes par le nom de ce qui, selon la conception de l'équipe de développement, deviendra la classe à laquelle ces méthodes seront rattachées. Cela facilitera la migration vers un outil orienté objet lorsque celle-ci sera entreprise.
Les fonctions globales et les méthodes publiques ont ceci en commun qu'une fois livrées, elles doivent être maintenues par la firme qui en est responsable. Ceci peut devenir une entrave au progrès, alors que les changements philosophiques et technologiques peuvent amener les gens à réclamer des changements à des fonctions existantes alors que d'autres peuvent réclamer d'elle une stabilité à toute épreuve.
Certaines firmes motiveront alors l'emploi de suffixes dénotant clairement le passage à une nouvelle génération du sous-programme. Ce suffixe peut être numérique (p. ex. : la nouvelle version de SousProgChic() devenant SousProgChic2()) ou dénoter le caractère extensionnel du sous-programme le plus récent (p. ex. : la nouvelle version de SousProgChic() devenant SousProgChicEx()). Dans les cas où le nouveau sous-programme dépasse le seuil de la simple extension fonctionnelle à l'original, on cherchera alors un nouveau nom, tout simplement.
Les règles pour joindre plusieurs mots en un même nom son en général les mêmes que celles appliquées pour les noms de variables.
Les règles de sous-programmes s'appliquent, dans l'ensemble, aux méthodes. Certains standards locaux existent (chez Oracle, avec Java, on commencera le nom des méthodes par une minuscule, alors que chez Microsoft, pour la bibliothèque MFC, on commencera plutôt par une majuscule), qui se valent à peu près tous dans la mesure où ils sont respectés de manière rigoureuse et sont respectueux de la culture des gens en place comme de celle de leurs clients.
La grande particularité des méthodes, par opposition aux sous-programmes globaux, est leur caractère subjectif. En effet, un sous-programme global est une opération qui s'applique à des entités qui lui sont fournies de l'extérieur. C'est un agent externe. Ceci est aussi en grande partie vrai pour la plupart des méthodes de classe.
Une méthode d'instance, par contre, opère d'abord et avant tout sur l'instance qui en est propriétaire, l'instance active. Les Get et les Set réfèrent à des données propres à l'objet possesseur de la méthode elle-même; cette méthode a ainsi un accès privilégié et implicite aux attributs en question.
Là où on nommait autrefois souvent un sous-programme global par une combinaison verbe/mot, comme dans AfficherDessin(d) ou AvancerVoiture(v), on simplifiera souvent le nom d'une méthode ou d'une fonction en se limitant à un verbe, l'objet de l'opération devenant un sujet (Avancer(d), Avancer(v)), et préfixant lors de l'appel la méthode (d.Afficher() ou v.Avancer()), présumant chaque fois que d soit un Dessin et v une Voiture.
Prenant le virage objet, cette simplification a l'avantage périphérique de ne pas lier le nom d'une méthode à un seul type de données mais plutôt à toute une hiérarchie d'objets. Ainsi, avec v.Avancer(), le nom de méthode Avancer() s'applique peut-être subjectivement à tout véhicule, qu'il s'agisse d'un Avion, d'une Voiture, d'un Bateau... la mécanique du polymorphisme fera en sorte de laisser le véhicule qu'est v, quel que soit son type réel, avancer de la manière la plus appropriée.
Une étrange conséquence
Il est important de noter que l'orientation objet a, parmi ses conséquences naturelles, celle de mener les langages à supporter plusieurs sous-programmes portant le même nom. La principale (mais pas la seule) raison pour ceci est la mécanique de construction des instances qui demande généralement qu'on puisse avoir plusieurs constructeurs distincts portant le même nom.
Sur le plan du code généré à la compilation, les noms doivent toutefois être uniques pour qu'on puisse différencier les sous-programmes à l'édition des liens. Pour arriver à des noms effectifs distincts mais reconnaissables, les compilateurs génèrent dans le code objet des noms de sous-programmes qui incluent de l'information quant aux types de leurs paramètres.
Ceci ajoute une strate de complexité à l'édition des liens, surtout lorsque survient le besoin de lier entre eux des fichiers objets générés à partir de langages de programmation et de compilateurs différents, puisque les standards d'encodage sont locaux aux technologies individuelles.
Pour faciliter les choses dans de tels cas, il arrivera qu'on introduise des sous-programmes globaux qui seront compilés selon les standards C (nom unique, nom dans le code objet correspondant directement au nom dans le code source) et qui serviront de lien entre les modules orientés objets et ceux qui ne le sont pas. Ceci résulte à l'occasion, côté orienté objet, en de curieux hybrides, mais tel est parfois le prix à payer pour assurer l'interopérabilité binaire.
