Solía haber muy buenas razones para mantener los nombres de instrucción / registro cortos. Esas razones ya no se aplican, pero los nombres crípticos cortos todavía son muy comunes en la programación de bajo nivel.
¿Por qué es esto? ¿Es solo porque los viejos hábitos son difíciles de romper, o hay mejores razones?
Por ejemplo:
- Atmel ATMEGA32U2 (2010?):
TIFR1
(en lugar deTimerCounter1InterruptFlag
),ICR1H
(en lugar deInputCapture1High
),DDRB
(en lugar deDataDirectionPortB
), etc. - Conjunto de instrucciones de .NET CLR (2002):
bge.s
(en lugar debranch-if-greater-or-equal.short
), etc.
¿No es más fácil trabajar con los nombres más largos y no crípticos?
Al responder y votar, tenga en cuenta lo siguiente. Muchas de las posibles explicaciones que se sugieren aquí se aplican igualmente a la programación de alto nivel, y, sin embargo, el consenso es, en general, utilizar nombres no crípticos que consisten en una palabra o dos (se excluyen las siglas entendidas comúnmente) .
Además, si su argumento principal es sobre espacio físico en un diagrama en papel , tenga en cuenta que esto no se aplica en absoluto al lenguaje ensamblador ni a CIL, y le agradecería que me mostrara un diagrama donde los nombres concisos encajan pero los legibles empeoran el diagrama. Desde la experiencia personal en una empresa de semiconductores fabless, los nombres legibles encajan bien y dan como resultado diagramas más legibles.
¿Cuál es la cosa central que es diferente en la programación de bajo nivel en comparación con los lenguajes de alto nivel que hace que los nombres crípticos concisos sean deseables en la programación de bajo nivel pero no en la de alto nivel ?