Discussion:Onomastique
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Nommage n'est pas fautif en informatique
[modifier le code]Le commentaire
"Par ignorance de l’existence du mot onomastique, on voit se répandre, en mercatique et en informatique notamment, l’usage fautif du néologisme « nommage », barbarisme inspiré par l’anglais naming."
me paraît erroné sinon fautif.
En effet, en informatique, le nommage est, au moins pour une acception, l'activité consistant à agencer des signes pour former un mot qui désignera quelque chose.
L'idée est que le quelque chose doit pouvoir être identifiable, au moins partiellement, à la lecture de son nom.
C'est couramment utilisé en informatique pour nommer des variables. Un exemple simple de programme sans, puis avec utilisation d'une convention de nommage, i.e. une liste de règles pour rendre les programmes plus lisibles et compréhensibles :
Sans convention de nommage :
i += j;
On ne sait pas ce qu'est i, ni j, et l'action représentée est au mieux très floue (peut-être une addition suivie d'une affectation ?).
En respectant une convention de nommage :
ensembleDAnimaux += unChat;
On peut ici imaginer que "ensembleDAnimaux" est une variable qui désigne un ensemble d'animaux, et "unChat" une variable qui désigne un chat.
On en déduit que l'action représentée par += est peut-être d'ajouter un chat dans un ensemble d'animaux.
Ce type de règle existe dans presque tout projet de codage informatique.
Un autre exemple, probablement moins lisible :
Ens453 += var_ctx_4;
Ici, on pourrait déduire de la majuscule d'"Ens453" que la variable est globale (allouée sur le tas), à l'existence durable, que c'est la 453ème créée par un générateur de code.
Quant à "var_ctx_4", il s'agirait de la 4ème variable d'un contexte donné (allouée sur la pile), à l'existence éphémère, liée à son contexte.
Maintenant qu'on a vu un exemple mettant en œuvre deux règles de nommage, revenons au commentaire.
D'après l'article : "L'onomastique est l'étude des noms propres."
Voici la définition, référencée dans l'article, que donne Wikipédia d'un nom propre :
"Un nom propre au contraire, désigne toute substance distincte de l'espèce à laquelle elle appartient. Il ne possède en conséquence aucune définition spécifique, sinon référentielle, et n'a de signification qu'en contexte, subjective, ou par des éléments de sa composition : Paris, Jules César, Louis XIV,Samson, Médor, Andersen, Apollon, Dieu, Au clair de la lune…".
Regardons celle que le TLFi donne à "nom" en grammaire :
"Partie du discours susceptible de prendre les marques de genre et de nombre, de remplir des fonctions grammaticales telles que sujet, attribut, complément et qui sert à désigner un être, une chose en particulier (nom propre) ou un individu en tant qu'il appartient à un ensemble d'individus semblables (nom commun).".
On pourrait partir du principe que, puisque nous fabriquons des noms (plein !), au fur et à mesure du codage, et que ces noms désignent une chose en particulier, qu'ils sont alors les noms propres de la chose désignée.
Sauf que ce principe ne tient pas du fait de la non unicité de la chose désignée. Si je dis "Paris", je parle de la capitale française, et de rien d'autre. On peut objecter que si j'habite au Texas, et que je demande mon chemin, près de la ville de Paris, une référence à "Paris" désignera probablement la ville de Paris au Texas, et non pas la capitale française. De l'unicité on peut glisser à un ensemble fini, de taille modeste, et connu à l'avance (invariable sans prendre en compte l'évolution de la langue) de choses désignées, dont le contexte doit permettre le choix pour lever l'ambiguïté.
Or, dans un langage informatique, une variable, dont le nom respecte donc peut-être une convention de nommage, peut désigner tour à tour des éléments particuliers, mais sans nécessairement que la chose désignée soit connue à l'avance. Il peut même arriver que la variable ne référence aucune chose (pointeur nul). On trouve difficilement des noms propres ne désignant aucune chose.
J'ajoute que si la variable ci-dessus est nommée "unChat" c'est pour préciser qu'on ne sait pas vraiment de quel chat il s'agit, il s'agit d'un chat, donc à l'évidence, on est très proche de la notion de nom commun.
De manière plus simple et générale, en informatique, on pratique l'artisanat de la fabrication de noms, qui est constitutive de l'activité de codage à de rares exceptions près*.
Il ne s'agit pas d'étudier des noms qui se seraient formés préalablement.
Vous l'aurez compris, je ne suis pas un spécialiste, et j'ai peut-être tort. Je supprimerai le commentaire à moins que mon erreur d'analyse soit clarifiée.
(*) On peut coder en langage machine directement, i.e. en valorisant des entiers : %11100000100000000001000000000001 est l'entier 3766489089 qu'on peut noter en hexadécimal 0xE0801001 et qui est, sauf erreur, l'instruction du processeur ARM qui additionne le registre r1 et le registre r0 et place le résultat dans r1.
On pourrait dire que 0xE0801001 (par exemple) est le nom propre de cette instruction. Elle est plus généralement notée "add r1,r0,r1". En admettant qu'on accepte le nom propre proposé précédemment, je doute que la personne qui aura fait l'effort de les apprendre tous puisse dialoguer avec beaucoup de monde. Quant à la notation de l'instruction, elle n'a rien d'un nom propre, bien que ses constituants en soient : add, r0 et r1 sont les noms propres de l'instruction du processeur et de ses registres. On pourrait arguer du fait que les registres réels dépendent du mode, et donc on alors affaire au principe de la liste finie, de taille modeste et connue à l'avance (les r14 de chaque mode du processeur, parfois notés r14_<mode> avec <mode> parmi { irq, svc, ... }).