Pourquoi les identificateurs courts cryptiques sont-ils encore si courants dans la programmation de bas niveau?


64

Auparavant, il y avait de très bonnes raisons de garder les noms d'instructions / registres brefs. Ces raisons ne s'appliquent plus, mais les noms cryptés courts sont encore très courants dans la programmation de bas niveau.

Pourquoi est-ce? Est-ce simplement parce que les vieilles habitudes sont difficiles à briser ou y a-t-il de meilleures raisons?

Par exemple:

  • Atmel ATMEGA32U2 (2010?): TIFR1(Au lieu de TimerCounter1InterruptFlag), ICR1H(au lieu de InputCapture1High), DDRB(au lieu de DataDirectionPortB), etc.
  • Jeu d'instructions .NET CLR (2002): bge.s(au lieu de branch-if-greater-or-equal.short), etc.

Les noms non cryptés, plus longs, ne sont-ils pas plus faciles à utiliser?


Lorsque vous répondez et votez, veuillez considérer les points suivants. Bon nombre des explications possibles suggérées ici s'appliquent également à la programmation de haut niveau, mais le consensus est généralement d'utiliser des noms non cryptés consistant en un mot ou deux (à l'exclusion des acronymes couramment compris).

En outre, si votre argument principal concerne l'espace physique sur un diagramme en papier , sachez que cela ne s'applique absolument pas au langage d'assemblage ni au langage CIL. De plus, j'apprécierais que vous me montriez un diagramme dans lequel les noms abrégés sont lisibles mais lisibles qui aggravent le diagramme. . D'après une expérience personnelle acquise dans une société de semi-conducteurs sans usine, les noms lisibles conviennent parfaitement et donnent des diagrammes plus lisibles.

Quelle est la chose principale qui est différent au sujet de la programmation de bas niveau , par opposition aux langages de haut niveau qui rend les noms énigmatiques laconiques souhaitables à faible niveau , mais pas de programmation de haut niveau?


82
Réponse: Pour que vous ayez l'impression de programmer dans un langage de bas niveau.
Thomas Eding

5
Cryptic est relatif. JSRest trois fois plus long que l'opcode qu'il représente ( $20sur un 6502) et considérablement plus facile à comprendre d'un coup d'œil.
Blrfl

4
Je suis un peu déçu, car la bonne réponse est là, mais ce n'est certainement pas celle acceptée. Avec les schémas de circuit, ces interruptions sont généralement nommées d'après les lignes auxquelles elles sont associées. Sur un schéma de circuit, vous ne voulez pas être détaillé, ce n'est pas une bonne pratique. Deuxièmement, le fait que vous n'aimiez pas les réponses ne signifie pas qu'elles ne sont pas correctes.
Jeff Langemeier

4
@gnat: essayer set Accumulator32 to BaseIndex32? Le simple élargissement des abréviations traditionnelles n’est pas le seul moyen de rendre quelque chose de plus lisible.
Timwi

1
"si votre argument principal concerne l'espace physique sur un diagramme en papier", non, il s'agit du fait qu'une bonne dénomination prend en compte autre chose que la clarté du nom (j'en ai donné dans ma réponse, diagrammes - inclus ceux dessinés sur un tableau - ne sont que quelques-unes de ces choses) et cette clarification est une chose relative (la familiarité a tendance à aider à la clarté quel que soit le choix, par exemple).
AProgrammer

Réponses:


106

La raison pour laquelle le logiciel utilise ces noms est que les feuilles de données utilisent ces noms. Comme le code à ce niveau est très difficile à comprendre sans la feuille de données, créer des noms de variables que vous ne pouvez pas rechercher est extrêmement inutile.

Cela soulève la question de savoir pourquoi les feuilles de données utilisent des noms abrégés. C'est probablement parce que vous avez souvent besoin de présenter les noms dans des tableaux comme celui-ci où vous n'avez pas de place pour les identifiants à 25 caractères:

Table TIFR1 de la fiche technique

En outre, des éléments tels que les schémas, les diagrammes d'épingles et les sérigraphies pour cartes de circuits imprimés sont souvent très exigus.


7
De plus, cette réponse ne concerne pas vraiment le côté logiciel pur, par exemple CLR, JVM, x86, etc. :)
Timwi

12
@romkyns: La raison pour laquelle ils ont utilisé ces noms abrégés est un peu plus évidente lorsque vous lisez ces fiches de données. Les fiches techniques d'un microcontrôleur que j'ai sous la main font environ 500 pages, même si vous utilisez des noms abrégés . La largeur des tableaux s’étendrait sur plusieurs pages / écrans si nous utilisions des noms plus longs, ce qui les rend très peu pratique pour utiliser une référence.
In silico

27
@romkyns: Les noms plus longs sont également consultables, mais ils sont "non natifs". Si vous écoutez des ingénieurs intégrés, ils disent en fait "tiffer zéro" et non "l'indicateur d'interruption du minuteur zéro". Je doute que les développeurs Web développent HTTP, HTML ou JSON dans leurs noms de méthodes.
TMN

6
@KarlBielefeldt er, quoi? :) Évidemment, je ne le trouverai pas dans la fiche technique actuelle car ils ont choisi le nom abrégé. Cela ne corrobore pas l'affirmation selon laquelle les noms abrégés sont plus facilement interrogeables ...
Roman Starkov

5
Ce ne sont pas seulement les feuilles de données qui sont contraintes d'espace, ce sont les schémas. Tous ces composants logiques ont des dérivations qui doivent être connectées à d'autres composants. "TimerCounter1InteruptFlag.clear" ne tient pas aussi bien sur une minuscule représentation filaire "TCIF.C"
AShelly

60

Loi de Zipf

Vous pouvez constater vous-même, en consultant ce texte, que la longueur des mots et la fréquence d'utilisation sont généralement inversement liées. Les mots qui sont très souvent utilisés, comme it, a, but, you, et andsont très courts, alors que les mots qui sont moins souvent utilisés comme des observe, comprehensionet verbositysont plus longs. Cette relation observée entre fréquence et longueur est appelée loi de Zipf .

Le nombre d'instructions dans le jeu d'instructions pour un microprocesseur donné se chiffre généralement par dizaines ou par centaines. Par exemple, le jeu d'instructions Atmel AVR semble contenir une centaine d'instructions distinctes (je n'ai pas compté), mais bon nombre d'entre elles sont des variantes d'un thème commun et ont des mnémoniques très similaires. Par exemple, les instructions de multiplication incluent MUL, MULS, MULSU, FMUL, FMULS et FMULSU. Vous n'avez pas à regarder la liste des instructions très longtemps avant de vous faire une idée générale que les instructions commençant par "BR" sont des branches, les instructions commençant par "LD" sont des charges, etc. Il en va de même pour les variables: Même les processeurs complexes n'offrent qu'un nombre limité d'emplacements pour stocker des valeurs: registres de conditions, registres à usage général, etc.

Comme il y a si peu d'instructions et que les noms longs prennent plus de temps, il est logique de leur donner des noms courts. En revanche, les langages de niveau supérieur permettent aux programmeurs de créer un grand nombre de fonctions, méthodes, classes, variables, etc. Chacune d'entre elles sera utilisée beaucoup moins fréquemment que la plupart des instructions d'assemblage, et des noms plus longs et plus descriptifs sont de plus en plus importants pour donner aux lecteurs (et aux auteurs) suffisamment d'informations pour comprendre ce qu'ils sont et ce qu'ils font.

De plus, les jeux d'instructions de différents processeurs utilisent souvent des noms similaires pour des opérations similaires. La plupart des jeux d'instructions comprennent des opérations pour ADD, MUL, SUB, LD, ST, BR, NOP, et s'ils n'utilisent pas ces noms exacts, ils utilisent généralement des noms très proches. Une fois que vous avez appris les mnémoniques pour un jeu d'instructions, il ne faut pas longtemps pour s'adapter aux jeux d'instructions d'autres périphériques. Ainsi , les noms qui pourraient sembler « cryptique » vous sont à peu près aussi familiers que des mots tels que and, oret notpour les programmeurs qui sont qualifiés dans l'art de la programmation de bas niveau. Je pense que la plupart des personnes travaillant au niveau des assemblées vous diraient qu'apprendre à lire le code n'est pas l'un des plus grands défis de la programmation de bas niveau.


2
merci Caleb! Pour moi, cette excellente réponse a sauvé une question qui avait réussi à rassembler quatre jugements de valeur dans un seul titre: "cryptique", "court", "immobile", "si commun"
gnat

1
Merci @gnat pour votre commentaire et votre généreux bonus.
Caleb

37

En général

La qualité des noms ne consiste pas uniquement à avoir des noms descriptifs, elle doit également prendre en compte d'autres aspects, ce qui conduit à des recommandations telles que:

  • plus la portée est globale, plus le nom doit être descriptif
  • plus il est utilisé souvent, plus le nom doit être court
  • le même nom doit être utilisé dans tous les contextes pour la même chose
  • des choses différentes devraient avoir des noms différents même si le contexte est différent
  • les variations doivent être facilement détectées
  • ...

Notez que ces recommandations sont en conflit.

Mnémotechnique

En tant que programmeur en langage assembleur, utiliser short-branch-if-greater-or-equalpour bge.sme donne la même impression que lorsque je vois, en tant que programmeur Algol qui effectue la géométrie informatique SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSau lieu de dx := p2.x - p1.x. Je ne peux tout simplement pas admettre que les premiers sont plus lisibles dans les contextes qui me sont chers.

Enregistrer les noms

Vous choisissez le nom officiel dans la documentation. La documentation sélectionne le nom de la conception. La conception utilise de nombreux formats graphiques où les noms longs ne sont pas adéquats et l'équipe de conception utilisera ces noms pendant des mois, voire des années. Pour les deux raisons, ils n'utiliseront pas le "drapeau d'interruption du premier compteur", ils l'abrègeront dans leur schéma ainsi que lorsqu'ils parleront. Ils le savent et utilisent des abréviations systématiques, par exemple TIFR1pour réduire les risques de confusion. Un point ici est que ce TIFR1n'est pas une abréviation aléatoire, c'est le résultat d'un schéma de nommage.


4
Est-ce TIFR1vraiment un meilleur schéma de nommage que InterruptFlag1si, ou IptFlag1si vous devez vraiment être bref?
Timwi

4
@ Timwi, InterruptFlaget IptFlagsont meilleurs que IFde la même manière que EnumerableInterfaceet ItfcEnumerablesont meilleurs que IEnumerable.
AProgrammer

@AProgrammer: Je considère votre réponse et votre commentaire comme les meilleurs et je les marquerais comme acceptés si je le pouvais. Ceux qui croient que seules les limites physiques dictent des noms abrégés ont tort. Cette discussion sera intéressante pour vous: 37signals.com/svn/posts/…
alpav

5
@alpav Savez-vous que votre lien soutient le contraire de ce que dit cette réponse? Si quelque chose, il prend pleinement en charge InterruptFlag1pour des raisons de clarté.
Roman Starkov

24

Hormis les "vieilles habitudes", le code Legacy, écrit il y a 30 ans et toujours utilisé, est très courant. Malgré ce que pensent certaines personnes moins expérimentées, refactoriser ces systèmes pour les rendre jolis coûte très cher pour un petit gain et n’est pas viable commercialement.

Les systèmes embarqués proches du matériel - et accédant aux registres, ont tendance à utiliser des étiquettes identiques ou similaires à celles utilisées dans les fiches techniques du matériel, pour de très bonnes raisons. Si le registre s'appelle XYZZY1 dans les feuilles de données matérielles, il est logique que la variable qui la représente soit probablement XYZZY1, ou si le programmeur passait une bonne journée, RegXYZZY1.

En ce qui concerne le bge.s, cela ressemble à l'assembleur - les quelques personnes qui ont besoin de le savoir plus longtemps sont moins lisibles. Si vous ne parvenez pas à vous concentrer bge.set à penser que branch-if-greater-or-equal.shortcela fera une différence - vous ne faites que jouer avec le CLR sans le savoir.

L’autre raison pour laquelle vous verrez des noms de variable courts est due au fait que les abréviations sont très répandues dans le domaine ciblé par le logiciel.

En résumé, des noms de variable abrégés qui reflètent une influence externe, tels que les normes de l'industrie et les fiches techniques matérielles, sont attendus. Les noms abrégés de variables internes au logiciel sont généralement moins souhaitables.


Si j'ai compris l'argument que vous utilisez pour défendre "bge.s", TIFR1est plus lisible pour ceux qui ont besoin de le savoir que TimerCounter1InterruptFlag, n'est-ce pas?
Roman Starkov

2
@romkyns: Absolument - dans ce cas, moins est plus .... Contrairement à CNTR, ce qui pourrait signifier "Compteur", "Contrôle", "Ne peut pas suivre l'itinéraire", etc. T1FR1 Signification précise.
mattnz

"Si vous ne parvenez pas à comprendre ce qui se passe et pensez que branchement-si-plus-ou-mieux. Un raccourci fera une différence - vous ne faites que jouer avec le CLR sans le savoir." Je n'en sais rien. Je comprends assez bien l'assemblage x86, mais chaque fois que j'écris une boucle, je dois rechercher la signification de toutes les j?instructions . Avoir une instruction plus clairement nommée m'aiderait certainement. Mais peut-être que je suis l'exception plutôt que la règle. J'ai du mal à me souvenir de détails triviaux.
Cody Gray

11

Il y a tellement d'idées différentes ici. Je ne peux accepter aucune des réponses existantes comme la réponse: d'une part, il existe probablement des facteurs qui contribuent à beaucoup cela, et d' autre part, je ne peux pas connaître peut - être que l' on est le plus important.

Alors, voici un résumé des réponses postées par d’autres ici. Je poste ceci en tant que CW et mon intention est de marquer finalement que cela est accepté. Veuillez éditer si j'ai manqué quelque chose. J'ai essayé de reformuler chaque idée pour l'exprimer de manière concise mais claire.

Alors, pourquoi les identifiants courts cryptiques sont-ils si courants dans la programmation de bas niveau?

  • Parce que beaucoup d'entre eux sont suffisamment communs dans le domaine respectif pour justifier un nom très court. Cela aggrave la courbe d'apprentissage, mais constitue un compromis intéressant compte tenu de la fréquence d'utilisation.
  • Parce qu’il ya généralement un petit ensemble de possibilités qui est corrigé (le programmeur ne peut pas ajouter à l’ensemble).
  • Parce que la lisibilité est une question d'habitude et de pratique. branch-if-greater-than-or-equal.shortest initialement plus lisible que bge.s, mais avec certaines pratiques, la situation est inversée.
  • Parce qu'ils doivent souvent être tapés à la main, parce que les langages de bas niveau ne sont souvent pas accompagnés d'IDE puissants dotés d'une bonne complétion automatique, ou que la climatisation n'est pas fiable.
  • Parce qu'il est parfois souhaitable de regrouper de nombreuses informations dans l'identifiant, et qu'un nom lisible aurait une longueur inacceptable, même selon des normes de haut niveau.
  • Parce que c’est à cela que ressemblaient les environnements de bas niveau. Rompre l'habitude nécessite un effort conscient, risque d'ennuyer ceux qui ont aimé les anciennes méthodes et doit être justifiée. S'en tenir à la manière établie est le "défaut".
  • Parce que beaucoup d'entre eux sont originaires d'autres sources, telles que les schémas et les feuilles de données. Ceux-ci, à leur tour, sont affectés par des contraintes d'espace.
  • Parce que les personnes chargées de nommer les choses n’ont même jamais considéré la lisibilité, ou ne réalisent pas qu’elles créent un problème, ou sont paresseuses.
  • Parce que dans certains cas, les noms sont devenus partie intégrante d’un protocole d’échange de données, tel que l’utilisation du langage assembleur en tant que représentation intermédiaire par certains compilateurs.
  • Parce que ce style est immédiatement reconnaissable comme étant de bas niveau et qu’il a donc l’air cool pour les geeks.

Personnellement, j’ai le sentiment que certaines d’entre elles ne contribuent pas réellement aux raisons pour lesquelles un système nouvellement développé choisirait ce style de nommage, mais j’ai pensé qu’il serait faux de filtrer certaines idées dans ce type de réponse.


10

Je vais jeter mon chapeau dans ce bazar.

Les conventions et normes de codage de haut niveau ne sont pas identiques aux normes et pratiques de codage de bas niveau. Malheureusement, la plupart d'entre eux sont des restes de code hérité et de processus de pensée anciens.

Certains, cependant, servent un but. Bien sûr, BranchGreaterThan serait beaucoup plus lisible que BGT , mais il existe actuellement une convention, une instruction et, en tant que telle, a acquis un peu de traction au cours des 30 dernières années d’utilisation standard. Pourquoi ont-ils commencé avec cela, probablement une limite de largeur de caractère arbitraire pour les instructions, les variables et autres; pourquoi le garde-t-il, c'est une norme. Cette norme est la même chose que d'utiliser int comme identifiant, il serait plus lisible d'utiliser Integer dans tous les cas, mais est-il nécessaire pour ceux qui programment depuis plus de quelques semaines ... non. Pourquoi? Parce que c'est une pratique courante.

Deuxièmement, comme je l’ai dit dans mon commentaire, bon nombre des interruptions sont nommées INTG1 et d’autres noms cryptés, qui ont également une fonction. Dans les schémas de circuit, il n’est PAS bon convention de nommer vos lignes et cela pourrait encombrer verbalement le schéma et nuire à la lisibilité. Toute verbosité est traitée dans la documentation. Et comme tous les schémas de câblage / circuits ont ces noms abrégés pour les lignes d'interruption, les interruptions elles-mêmes ont également le même nom afin de préserver la cohérence du concepteur intégré depuis le schéma de circuit jusqu'au code pour le programmer.

Un concepteur a un certain contrôle sur cela, mais comme dans tout langage de champ / nouveau, des conventions suivent, matériel à matériel, et doivent donc rester identiques dans tous les langages d'assemblage. Je peux regarder un extrait d'assemblage et être capable de comprendre l'essentiel du code sans jamais utiliser ce jeu d'instructions, car il s'en tient à une convention, à une convention LDA ou à une relation qui le lie est probablement en train de charger un registre. MV déplace probablement quelque chose de quelque part vers ailleurs, il ne s'agit pas de ce que vous jugez bon ou de pratique de haut niveau, mais bien de la langue. En tant que tel, il a ses propres normes et signifie que vous, en tant que concepteur, devez les suivre. Elles ne sont souvent pas aussi arbitraires que ils semblent.

Je vous laisse avec ceci: Demander à la communauté intégrée d’utiliser des pratiques verbeuses de haut niveau revient à demander aux chimistes d’écrire en permanence des composés chimiques. Le chimiste les écrit brièvement pour eux-mêmes et tout le monde le comprendra, mais il faudra peut-être un peu de temps au nouveau venu pour s’adapter.


1
Je pense que « nous utiliserons des noms énigmatiques parce que ce qui rend la programmation de bas niveau se sentent en tant que tel » et « nous utiliserons des noms énigmatiques parce que c'est la convention pour la programmation de bas niveau » sont à peu près les mêmes, +1 de moi et je penserai à accepter cela comme une variante moins inflammatoire de celle que j’ai acceptée au départ .
Roman Starkov

6
+1 pour la référence des chimistes car il génère une bonne analogie pour les différents domaines de la programmation.

4
+1 Je n'ai jamais compris non plus pourquoi les gens utilisent des noms courts et cryptiques comme "eau" s'il existe le "DiHydrogenOxyde" beaucoup plus lisible
Ingo

6

Une des raisons pour lesquelles ils utilisent des identificateurs courts cryptiques est qu’ils ne le sont pas pour les développeurs. Vous devez réaliser qu'ils travaillent avec cela tous les jours et que ces noms sont vraiment des noms de domaine. Donc, ils savent par cœur ce que TIFR1 signifie exactement.

Si un nouveau développeur arrive dans l'équipe, il devra lire les fiches techniques (comme l'explique @KarlBielefeldt) pour se familiariser avec celles-ci.

Je pense que votre question utilise un mauvais exemple car en effet, sur ce type de code source, vous voyez généralement de nombreux identifiants de cryptage inutiles pour des éléments ne relevant pas du domaine.

Je dirais surtout qu'ils le font en raison de mauvaises habitudes qui existaient lorsque les compilateurs ne complétaient pas automatiquement tout ce que vous tapez.


5

Sommaire

L'initialisme est un phénomène omniprésent dans de nombreux cercles techniques et non techniques. En tant que tel, il ne se limite pas à la programmation de bas niveau. Pour la discussion générale, voir l'article de Wikipedia sur Acronym . Ma réponse est spécifique à la programmation de bas niveau.

Causes des noms cryptiques:

  1. Les instructions de bas niveau sont fortement typées
  2. Nécessité d'intégrer beaucoup d'informations de type dans le nom d'une instruction de bas niveau
  3. Historiquement, les codes à caractère unique sont privilégiés pour la saisie des informations de type.

Les solutions et leurs inconvénients:

  1. Il existe des schémas de nommage de bas niveau modernes qui sont plus cohérents que les historiques.
    • LLVM
  2. Cependant, la nécessité de rassembler beaucoup d'informations de type existe toujours.
    • Ainsi, les abréviations cryptiques peuvent encore être trouvées partout.
  3. Une lisibilité améliorée de ligne à ligne aidera un programmeur débutant novice à maîtriser la langue plus rapidement, mais ne facilitera pas la compréhension de gros morceaux de code de bas niveau.

Réponse complète

(A) Des noms plus longs sont possibles. Par exemple, les noms des éléments intrinsèques C ++ SSE2 comportent en moyenne 12 caractères, par rapport aux 7 caractères du mnémonique d’assemblage. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) La question passe ensuite à la question suivante: Combien de temps doit-on obtenir sans instructions cryptées à partir d'instructions de bas niveau?

(C) Nous analysons maintenant la composition de tels schémas de nommage. Voici deux schémas de nommage pour la même instruction de bas niveau:

  • Schéma de nommage n ° 1: CVTSI2SD
  • Schéma de nommage n ° 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Les instructions de bas niveau sont toujours fortement typées. Il ne peut y avoir d'ambiguïté, d'inférence de type, de conversion de type automatique ou de surcharge (réutilisation du nom de l'instruction pour désigner des opérations similaires mais non équivalentes).

(C.2) Chaque instruction de bas niveau doit coder un grand nombre d'informations de type dans son nom. Exemples d'informations:

  • Famille d'architecture
  • Opération
  • Arguments (entrées) et sorties
  • Types (Entier Signé, Entier Non Signé, Flottant)
  • Précision (largeur de bit)

(C.3) Si chaque information est épelée, le programme sera plus détaillé.

(C.4) Les schémas de codage de type utilisés par divers fournisseurs avaient de longues racines historiques. Par exemple, dans le jeu d'instructions x86:

  • B signifie octet (8 bits)
  • W signifie mot (16 bits)
  • D signifie dword "double-mot" (32 bits)
  • Q signifie qword "quad-word" (64 bits)
  • DQ signifie dqword "double-quad-word" (128 bits)

Ces références historiques n’avaient aucune signification moderne, mais restaient toujours présentes. Un schéma plus cohérent aurait mis la valeur de la largeur de bit (8, 16, 32, 64, 128) dans le nom.

Au contraire, LLVM est un pas en avant dans la direction de la cohérence des instructions de bas niveau: http://llvm.org/docs/LangRef.html#functions

(D) Indépendamment du schéma de nommage des instructions, les programmes de bas niveau sont déjà verbeux et difficiles à comprendre car ils se concentrent sur les moindres détails de l'exécution. Changer le schéma de nommage des instructions améliorera la lisibilité ligne par ligne, mais n'éliminera pas la difficulté de comprendre les opérations d'un gros morceau de code.


1
L’amélioration de la lisibilité entre les lignes aura nécessairement un impact sur la compréhension de l’ensemble, mais le nom seul ne peut naturellement pas le rendre trivial.
Roman Starkov

3
Aussi, en quelque sorte hors sujet, mais CVTSI2SDne contient pas plus d'informations que ConvertDword2Doubleou ConvInt32ToFloat64, mais ces derniers, bien que plus longs, sont immédiatement reconnaissables, alors que les premiers doivent être déchiffrés ...
Roman Starkov

2

Les humains ne lisent et n'écrivent des assemblages qu'occasionnellement, et il ne s'agit généralement que d'un protocole de communication. C'est-à-dire qu'il est le plus souvent utilisé comme une représentation textuelle intermédiaire sérialisée entre le compilateur et l'assembleur. Plus cette représentation est détaillée, plus le protocole est inutile.

Dans le cas des opcodes et des noms de registre, les noms longs nuisent à la lisibilité. Les mnémoniques courts sont préférables pour un protocole de communication (entre compilateur et assember), et le langage assembleur est la plupart du temps un protocole de communication. Les mnémoniques courts conviennent mieux aux programmeurs, car le code du compilateur est plus facile à lire.


Si vous avez besoin d'économiser de l'espace, il suffit de gzip-le! ... Si vous n'avez pas besoin de surcharge, utilisez plutôt un format binaire! Si vous utilisez du texte, vous visez la lisibilité - alors pourquoi ne pas aller jusqu'au bout et le rendre correctement lisible?
Roman Starkov

2
@romkyns, compression d'un protocole de communication textuel entre deux processus locaux? C'est quelque chose de nouveau. Les protocoles binaires sont beaucoup moins robustes. C'est un moyen unique: les protocoles textuels sont là pour une lisibilité occasionnelle . Ils sont lisibles juste assez.
SK-logic

Droite. Votre hypothèse est que je lis et écris les noms de ces registres ou instructions CIL assez peu pour que les frais généraux importent. Mais réfléchis-y; ils sont utilisés aussi souvent que n'importe quelle méthode ou nom de variable impair dans tout autre langage de programmation pendant la programmation . Est-ce si rare que les quelques octets supplémentaires importent?
Roman Starkov

1
Je respecte votre droit d'avoir un goût différent quant à la longueur des noms, mais nommez-vous vraiment les méthodes et les locales dans vos compilateurs comme des choses cryptiques TIFR, ou ont-elles tendance à contenir des mots entiers?
Roman Starkov

1
Je ne vois aucune différence pertinente entre le compromis lisible et court. Je les vois comme différentes, bien sûr, tout comme les variables sont différentes des fonctions qui diffèrent des types. Je ne vois tout simplement pas pourquoi les opcodes et les noms de registre tirent avantage de leur extrême brièveté au point de devoir consulter la documentation de chaque document rencontré avant que vous ne sachiez ce que cela signifie. Votre seul argument à ce jour est un stockage efficace, si je ne me trompe pas. Est-ce que tu le penses vraiment ? ... Ou as-tu d'autres raisons?
Roman Starkov

1

Surtout c'est idiomatique. Comme @TMN le dit ailleurs, tout comme vous n'écrivez pas import JavaScriptObjectNotationou import HypertextTransferProtocolLibraryen Python, vous n'écrivez pas Timer1LowerHalf = 0xFFFFen C. Cela semble tout aussi ridicule dans son contexte. Tous ceux qui ont besoin de savoir le savent déjà.

La résistance au changement peut provenir en partie du fait que certains éditeurs de compilateurs C pour systèmes intégrés s’écartent de la syntaxe et des normes de langage afin d’implémenter des fonctionnalités plus utiles à la programmation intégrée. Cela signifie que vous ne pouvez pas toujours utiliser la fonctionnalité de saisie semi-automatique de votre éditeur de texte ou IDE préféré lors de l'écriture de code de bas niveau, car ces personnalisations empêchent toute analyse du code. D'où l'utilité des noms de registres courts, des macros et des constantes.

Par exemple, le compilateur C de HiTech incluait une syntaxe spéciale pour les variables qui devaient avoir une position spécifiée par l'utilisateur en mémoire. Vous pourriez déclarer:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

À présent, le seul IDE existant qui va analyser ceci est le propre IDE de HiTech ( HiTide ). Dans tout autre éditeur, vous devrez le saisir manuellement, à partir de la mémoire, à chaque fois. Cela vieillit très vite.

De plus, lorsque vous utilisez des outils de développement pour inspecter les registres, vous obtenez souvent un tableau avec plusieurs colonnes (nom du registre, valeur en hexadécimal, valeur en binaire, dernière valeur en hexadécimale, etc.). Les noms longs signifient que vous devez étendre la colonne de noms à 13 caractères pour voir la différence entre deux registres et jouer à "repérer la différence" sur des dizaines de lignes de mots répétés.

Cela peut sembler ridicule, mais toutes les conventions de codage ont-elles pour but de réduire la fatigue oculaire, les saisies superflues ou d’aborder toutes les autres petites plaintes?


2
Tous vos arguments ont un sens. Je comprends parfaitement tous ces points. Cependant, ne pensez-vous pas que la même chose s'applique exactement au code de haut niveau? Vous devez également voir une table de locaux dans une fonction C #. Le contexte est subjectif et File.ReadAllBytespeut sembler ridiculement long à quelqu'un d'autre fread. Alors ... pourquoi traiter le code de haut niveau et le code de bas niveau différemment ?
Roman Starkov

@romkyns - Je comprends votre point de vue, mais je ne pense pas que nous ne traitons pas vraiment le code de haut niveau de manière très différente. Les abréviations conviennent dans de nombreux contextes de haut niveau. Nous ne le réalisons tout simplement pas, car nous sommes plus habitués à l’abréviation ou à tout autre schéma qui va avec. Quand j'écris des fonctions ou crée des variables dans un code de bas niveau, j'utilise de jolis noms descriptifs. Mais lorsque je me réfère à un registre, je suis heureux de pouvoir jeter un coup d'œil à un mélange de lettres et de chiffres et de penser rapidement "T = minuteur, indicateur d'interruption, 1 = premier registre". C'est presque comme de la chimie organique à cet égard: P
vraiment

@romkyns - En outre, dans un sens purement pratique, je pense que la différence entre une table de registres IDE et le développement d' applications en C # de certains microprocesseur est le suivant: une table de registres uP pourrait ressembler à : Timer1InterruptFlag, Timer2InterruptFlag, ..., Timer9InterruptFlag, IOPortAToggleMask, IOPortBToggleMask, etc x100. Dans un langage de niveau supérieur, vous utiliseriez des variables qui diffèrent beaucoup plus ... ou une structure plus complexe. Timer1InterruptFlagest 75% de bruit non pertinent par rapport à T1IF. Je ne pense pas que vous créeriez une liste énorme de variables en C # qui diffèrent à peine de cette façon.
Détly

1
@romkyns - Ce que vous ignorez peut-être, c'est qu'il y a eu un changement vers ce que vous décrivez. Les compilateurs récents de Microchip sont livrés avec des bibliothèques beaucoup plus détaillées et descriptives que de simples registres, par exemple. UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200). Mais ils sont encore incroyablement maladroits et impliquent beaucoup d’indirection et d’inefficacité. J'essaie de les utiliser autant que possible, mais la plupart du temps, je range la manipulation des registres dans mes propres fonctions et l'appelle depuis la logique de niveau supérieur.
Détly

@detly: Le compilateur CCS avait de telles méthodes, et d'autres processeurs en ont. Je ne les aime généralement pas. La spécification de registre est suffisante pour écrire du code qui utilise les registres et pour permettre à quelqu'un qui lit le code qui utilise des registres de voir ce que font ces registres. Si l'acte d'écrire une valeur de N sur une clé physique matérielle établit la période sur N + 1 (assez commun), le sens correct de set_prescalar(TMR4,13);IMHO est bien moins clair qu'il ne le serait TMR4->PSREG=12;. Même si l' on regarde le manuel du compilateur pour savoir ce que le premier code fait, on aura probablement encore avoir à ...
supercat

1

Je suis surpris que personne n'ait mentionné la paresse et que d'autres sciences ne soient pas abordées. Mon travail quotidien en tant que programmeur me montre que les conventions de dénomination pour tout type de variable dans un programme sont influencées par trois aspects différents:

  1. Le fond scientifique du programmeur.
  2. Les compétences de programmation du programmeur.
  3. L'environnement du programmeur.

Je pense qu'il est inutile de discuter de programmation de bas niveau ou de haut niveau. À la fin, il peut toujours être épinglé aux trois premiers aspects.


Une explication du premier aspect: beaucoup de "programmeurs" ne sont pas des programmeurs en premier lieu. Ils sont mathématiciens, physiciens, biologistes ou même psychologues ou économistes, mais nombre d'entre eux ne sont pas des informaticiens. La plupart d’entre eux ont leurs propres mots-clés et abréviations spécifiques à un domaine que vous pouvez voir dans leurs "conventions" de dénomination. Ils sont souvent piégés dans leur domaine et utilisent les abréviations connues sans se soucier de la lisibilité ni des guides de codage.

Une explication du deuxième aspect: la plupart des programmeurs n’étant pas des informaticiens, leurs compétences en programmation sont limitées. C’est pourquoi ils se moquent bien souvent des conventions de codage mais plus des conventions propres à un domaine, comme indiqué en premier. De plus, si vous ne possédez pas les compétences d'un programmeur, vous ne comprenez pas les conventions de codage. Je pense que la plupart d'entre eux ne voient pas le besoin urgent d'écrire un code compréhensible. C'est comme le feu et oublier.

Une explication du troisième aspect: Il est peu probable que vous respectiez les conventions de votre environnement qui peuvent être des codes anciens que vous devez supporter, des normes de codage de votre société (gérées par des économistes peu soucieux du codage) ou du domaine auquel vous appartenez. Si quelqu'un a commencé à utiliser des noms cryptés et que vous devez le prendre en charge, il est peu probable que vous changiez les noms cryptés. S'il n'y a pas de normes de codage dans votre entreprise, je parie que presque tous les programmeurs écriront leurs propres normes. Enfin, si vous êtes entouré d’utilisateurs du domaine, vous ne commencerez pas à écrire une langue différente de celle qu’ils utilisent.


personne n'a mentionné la paresse - c'est peut-être parce que ce n'est pas pertinent ici. Et que d'autres sciences ne sont pas abordées, c'est facile: ce site n'est pas pour la discussion . C'est pour des questions et des réponses
moucher le

La paresse est une raison légitime. Presque tous les programmeurs sont des paresseux (sinon nous ferions tout manuellement ooo!).
Thomas Eding
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.