¿Por qué los identificadores cortos crípticos siguen siendo tan comunes en la programación de bajo nivel?

64

Solía ​​haber muy buenas razones para mantener cortos los nombres de instrucción / registro. Esas razones ya no se aplican, pero los nombres crípticos cortos siguen siendo 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 de TimerCounter1InterruptFlag), ICR1H(en lugar de InputCapture1High), DDRB(en lugar de DataDirectionPortB), etc.
  • Conjunto de instrucciones .NET CLR (2002): bge.s(en lugar de branch-if-greater-or-equal.short), etc.

¿No son los nombres largos y no crípticos más fáciles de trabajar?


Al responder y votar, tenga en cuenta lo siguiente. Muchas de las posibles explicaciones sugeridas aquí se aplican igualmente a la programación de alto nivel, y, sin embargo, el consenso, en general, es usar nombres no crípticos que consisten en una o dos palabras (excluidas las siglas comúnmente entendidas).

Además, si su argumento principal es sobre el espacio físico en un diagrama en papel , tenga en cuenta que esto no se aplica en absoluto al lenguaje ensamblador o CIL, además le agradecería que me muestre un diagrama donde los nombres concisos se ajustan pero los legibles empeoran el diagrama. . Por experiencia personal en una compañía de semiconductores sin fábrica, los nombres legibles encajan perfectamente y dan como resultado diagramas más legibles.

¿Cuál es la cosa principal que es diferente acerca de la programación de bajo nivel en comparación con lenguajes de alto nivel que hace que los nombres crípticos lacónicas deseables de bajo nivel, pero no de programación de alto nivel?

Roman Starkov
fuente
82
Respuesta: Para que parezca que estás programando en un lenguaje de bajo nivel.
Thomas Eding
55
Críptico es relativo. JSRes tres veces más largo que el código de operación que representa ( $20en un 6502) y considerablemente más fácil de entender de un vistazo.
Blrfl
44
Estoy un poco decepcionado, porque la respuesta correcta está ahí, pero definitivamente no es la aceptada. Con los diagramas de circuito y tales interrupciones generalmente se nombran después de las líneas con las que están asociadas, y en un diagrama de circuito que no se quiere detallar, no es una buena práctica o práctica. En segundo lugar, porque no te gustan las respuestas no significa que no sean correctas.
Jeff Langemeier
44
@gnat: set Accumulator32 to BaseIndex32¿ Intentar ? Simplemente expandir las abreviaturas tradicionales no es la única forma de hacer que algo sea más legible.
Timwi
1
"si su argumento principal es sobre el espacio físico en un diagrama de papel", no, se trata del hecho de que una buena denominación toma en cuenta otras cosas además de la claridad del nombre (di algunos en mi respuesta, diagramas, incluidos los que se dibujan en una pizarra - son solo una de estas otras cosas) y que aclarar es algo relativo (la familiaridad tiende a ayudar a aclarar cualquiera que sea la opción, por ejemplo).
Programador

Respuestas:

106

La razón por la que el software usa esos nombres es porque las hojas de datos usan esos nombres. Dado que el código en ese nivel es muy difícil de entender sin la hoja de datos de todos modos, hacer nombres de variables que no puede buscar es extremadamente inútil.

Eso plantea la pregunta de por qué las hojas de datos usan nombres cortos. Probablemente se deba a que a menudo necesita presentar los nombres en tablas como esta donde no tiene espacio para identificadores de 25 caracteres:

Tabla TIFR1 de la hoja de datos

Además, cosas como esquemas, diagramas de pines y serigrafías de PCB a menudo son muy estrechas para el espacio.

Karl Bielefeldt
fuente
77
Además, esta respuesta realmente no aborda el lado del software puro, por ejemplo, CLR, JVM, x86, etc. :)
Timwi
12
@romkyns: Es un poco más obvio por qué usaron estos nombres cortos cuando realmente lees estas hojas de datos. Las hojas de datos para un microcontrolador que tengo a mano son aproximadamente 500 páginas, incluso cuando se usan los nombres cortos . El ancho de las tablas abarcaría varias páginas / pantallas si utilizáramos nombres más largos, lo que las hace muy inconvenientes para usar una referencia.
En silico
27
@romkyns: los nombres más largos se pueden buscar por igual, pero son "no nativos". Si escucha a los ingenieros integrados, en realidad dicen "tiffer zero", no "bandera de interrupción del temporizador cero". Dudo que los desarrolladores web expandan HTTP, HTML o JSON en sus nombres de métodos, tampoco.
TMN
66
@KarlBielefeldt er, ¿qué? :) Obviamente no lo encontraré en la hoja de datos actual porque eligieron el nombre corto. Eso no respalda la afirmación de que los nombres cortos son más buscables en lo más mínimo ...
Roman Starkov
55
No son solo las hojas de datos las que tienen limitaciones de espacio, son los esquemas. Todos esos componentes lógicos tienen cables que deben conectarse a otros componentes. "TimerCounter1InteruptFlag.clear" no cabe en la parte superior de una pequeña representación de cable casi tan bien "TCIF.C"
AShelly
60

Ley de Zipf

Usted mismo puede observar al mirar este mismo texto que la longitud de las palabras y la frecuencia de uso están, en general, inversamente relacionadas. Las palabras que se utilizan con mucha frecuencia, como it, a, but, you, y andson muy cortos, mientras que las palabras que se utilizan con menos frecuencia les gusta observe, comprehensiony verbosityson más largos. Esta relación observada entre frecuencia y longitud se llama Ley de Zipf .

El número de instrucciones en el conjunto de instrucciones para un microprocesador dado suele ser de docenas o cientos. Por ejemplo, el conjunto de instrucciones Atmel AVR parece contener alrededor de un centenar de instrucciones distintas (no conté), pero muchas de ellas son variaciones sobre un tema común y tienen mnemónicos muy similares. Por ejemplo, las instrucciones de multiplicación incluyen MUL, MULS, MULSU, FMUL, FMULS y FMULSU. No tiene que mirar la lista de instrucciones por mucho tiempo antes de tener la idea general de que las instrucciones que comienzan con "BR" son ramas, las instrucciones que comienzan con "LD" son cargas, etc. Lo mismo se aplica a las variables: Incluso los procesadores complejos proporcionan solo un número limitado de lugares para almacenar valores: registros de condición, registros de propósito general, etc.

Debido a que hay muy pocas instrucciones y a que los nombres largos tardan más en leerse, tiene sentido darles nombres cortos. Por el contrario, los lenguajes de nivel superior permiten a los programadores crear una gran cantidad de funciones, métodos, clases, variables, etc. Cada uno de estos se utilizará con mucha menos frecuencia que la mayoría de las instrucciones de ensamblaje, y los nombres más largos y descriptivos son cada vez más importantes para dar a los lectores (y escritores) suficiente información para comprender qué son y qué hacen.

Además, los conjuntos de instrucciones para diferentes procesadores a menudo usan nombres similares para operaciones similares. La mayoría de los conjuntos de instrucciones incluyen operaciones para ADD, MUL, SUB, LD, ST, BR, NOP, y si no usan esos nombres exactos, generalmente usan nombres que están muy cerca. Una vez que haya aprendido la mnemotecnia para un conjunto de instrucciones, no tardará mucho en adaptarse a los conjuntos de instrucciones para otros dispositivos. Así que los nombres que podrían parecer "críptica" a que son casi tan familiar como palabras como and, ory nota los programadores que son expertos en el arte de la programación de bajo nivel. Creo que la mayoría de las personas que trabajan en el nivel de ensamblado le diría que aprender a leer el código no es uno de los mayores desafíos en la programación de bajo nivel.

Caleb
fuente
2
gracias Caleb! Para mí, esta excelente respuesta rescató una pregunta que de alguna manera logró reunir cuatro juicios de valor en un título: "críptico", "corto", "aún", "muy común"
mosquito
1
Gracias, @gnat, tanto por tu comentario como por tu generoso bono.
Caleb
37

En general

La calidad de los nombres no se trata solo de tener nombres descriptivos, sino que también debe considerar otros aspectos, y eso lleva a recomendaciones como:

  • cuanto más global es el alcance, más descriptivo debe ser el nombre
  • cuanto más se usa, más corto debe ser el nombre
  • el mismo nombre debe usarse en todos los contextos para la misma cosa
  • diferentes cosas deben tener diferentes nombres incluso si el contexto es diferente
  • las variaciones deben detectarse fácilmente
  • ...

Tenga en cuenta que estas recomendaciones son contradictorias.

Instrucción mnemónica

Como programador de lenguaje ensamblador, usar short-branch-if-greater-or-equalfor bge.sme da la misma impresión que cuando veo, como un programador Algol haciendo geometría computacional, en 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-POINTSlugar de dx := p2.x - p1.x. Simplemente no puedo aceptar que los primeros sean más legibles en los contextos que me interesan.

Registrar nombres

Elige el nombre oficial de la documentación. La documentación elige el nombre del diseño. El diseño utiliza muchos formatos gráficos donde los nombres largos no son adecuados y el equipo de diseño vivirá con esos nombres durante meses, si no años. Por ambas razones, no usarán "Indicador de interrupción del primer contador de temporizador", lo abreviarán en su esquema así como cuando hablen. Lo saben y usan abreviaturas sistemáticas como TIFR1para que haya menos posibilidades de confusión. Un punto aquí es que TIFR1no es una abreviatura aleatoria, es el resultado de un esquema de nombres.

Un programador
fuente
44
¿Es TIFR1realmente un mejor esquema de nombres de lo InterruptFlag1que es, o IptFlag1si realmente tiene que ser breve?
Timwi
44
@Timwi, InterruptFlagy IptFlagson mejores que IFde la misma manera que EnumerableInterfacey ItfcEnumerableson mejores que IEnumerable.
Programador
@AProgrammer: Considero que su respuesta y su comentario son los mejores y lo marcaría como aceptado si pudiera. Los que creen que solo los límites físicos dictan los nombres cortos están equivocados. Esta discusión será interesante para usted: 37signals.com/svn/posts/…
alpav
55
@alpav ¿Te das cuenta de que tu enlace argumenta lo contrario de lo que dice esta respuesta? En todo caso, es totalmente compatible InterruptFlag1por razones de mayor claridad.
Roman Starkov el
24

Además de las razones de los "viejos hábitos", el código heredado que se escribió hace 30 años y todavía está en uso es muy común. A pesar de lo que piensan algunas personas menos experimentadas, refactorizar estos sistemas para que se vean bonitos tiene un costo muy alto por una pequeña ganancia y no es comercialmente viable.

Los sistemas integrados que están cerca del hardware, y al acceder a los registros, tienden a usar las mismas etiquetas o etiquetas similares a las utilizadas en las hojas de datos del hardware, por muy buenas razones. Si el registro se llama XYZZY1 en las hojas de datos de hardware, tiene sentido que la Variable que lo representa probablemente sea XYZZY1, o si el programador estaba teniendo un buen día, RegXYZZY1.

En cuanto a bge.s, es similar al ensamblador: para las pocas personas que necesitan saberlo, los nombres más largos son menos legibles. Si no puede entenderlo bge.sy piensa branch-if-greater-or-equal.shortque hará la diferencia, simplemente está jugando con el CLR y no lo sabe.

La otra razón por la que verá nombres cortos de variables se debe a la amplia difusión de abreviaturas dentro del dominio al que apunta el software.

En resumen: se esperan nombres abreviados cortos de variables que reflejen una influencia externa, como las normas de la industria y las hojas de datos de hardware. Los nombres cortos de variables abreviadas que son internos al software normalmente son menos deseables.

Mattnz
fuente
Si entendí el argumento que usas para defender "bge.s", ¿ TIFR1es más legible para aquellos que necesitan saberlo que TimerCounter1InterruptFlagcorrecto?
Roman Starkov
2
@romkyns: Absolutamente, en este caso, menos es más ... A diferencia del CNTR, que podría significar "Contador", "Control", "No se puede rastrear la ruta", etc., T1FR1 Significado definido con precisión.
mattnz
"Si no puedes entender bge.s y piensas que branch-if-major-or-equal.short hará la diferencia, simplemente estás jugando con el CLR y no lo sabes". No se sobre eso. Entiendo bastante bien el ensamblaje x86, pero cada vez que escribo un bucle, tengo que buscar qué significan todas las j?instrucciones . Tener una instrucción más obviamente nombrada definitivamente me ayudaría. Pero tal vez soy la excepción más que la regla. Tengo problemas para recordar detalles triviales.
Cody Gray
11

Hay tantas ideas diferentes aquí. No puedo aceptar ninguna de las respuestas existentes como la respuesta: en primer lugar, es probable muchos factores que contribuyen a esto, y en segundo lugar, no puede saber cuál es el más significativo.

Así que aquí hay un resumen de las respuestas publicadas por otros aquí. Estoy publicando esto como CW y mi intención es eventualmente marcarlo como aceptado. Edite si me perdí algo. Traté de reformular cada idea para expresarla de manera concisa pero clara.

Entonces, ¿por qué los identificadores cortos crípticos son tan comunes en la programación de bajo nivel?

  • Debido a que muchos de ellos son lo suficientemente comunes en el dominio respectivo para garantizar un nombre muy corto. Esto empeora la curva de aprendizaje, pero es una compensación que vale la pena dada la frecuencia de uso.
  • Debido a que generalmente hay un pequeño conjunto de posibilidades que es fijo (el programador no puede agregar al conjunto).
  • Porque la legibilidad es una cuestión de hábito y práctica. branch-if-greater-than-or-equal.shortes inicialmente más legible que bge.s, pero con algo de práctica la situación se revierte.
  • Debido a que a menudo tienen que escribirse en su totalidad, a mano, porque los idiomas de bajo nivel a menudo no vienen con IDE potentes que tienen una buena autocompletación, o el a / c no es confiable.
  • Debido a que a veces es deseable incluir una gran cantidad de información en el identificador, y un nombre legible sería inaceptablemente largo incluso para los estándares de alto nivel.
  • Porque así es como se han visto históricamente los entornos de bajo nivel. Romper el hábito requiere un esfuerzo consciente, corre el riesgo de molestar a los que les gustaban las viejas costumbres y debe justificarse como valioso. Seguir el camino establecido es el "predeterminado".
  • Porque muchos de ellos se originan en otros lugares, como esquemas y hojas de datos. Aquellos, a su vez, se ven afectados por limitaciones de espacio.
  • Porque las personas a cargo de nombrar cosas nunca han considerado la legibilidad, o no se dan cuenta de que están creando un problema, o son flojos.
  • Porque en algunos casos los nombres se han convertido en parte de un protocolo para el intercambio de datos, como el uso del lenguaje ensamblador como una representación intermedia por parte de algunos compiladores.
  • Porque este estilo es instantáneamente reconocible como de bajo nivel y, por lo tanto, se ve genial para los geeks.

Personalmente, creo que algunos de estos no contribuyen realmente a las razones por las que un sistema recientemente desarrollado elegiría este estilo de nomenclatura, pero sentí que sería un error filtrar algunas ideas en este tipo de respuesta.

Roman Starkov
fuente
10

Voy a tirar mi sombrero en este desastre.

Las convenciones y estándares de codificación de alto nivel no son lo mismo que las normas y prácticas de codificación de bajo nivel. Desafortunadamente, la mayoría de ellos son restos del código heredado y los viejos procesos de pensamiento.

Algunos, sin embargo, tienen un propósito. Claro, BranchGreaterThan sería mucho más legible que BGT , pero hay una convención allí ahora, es una instrucción y, como tal, ha ganado algo de tracción en los últimos 30 años de uso como estándar. Por qué empezaron con él, probablemente algún límite de ancho de caracteres arbitrario para instrucciones, variables y demás; por qué lo guardan, es un estándar. Este estándar es el mismo que usar int como identificador, sería más legible usar Integer en todos los casos, pero es necesario para cualquier persona que haya estado programando más de unas pocas semanas ... no. ¿Por qué? Porque es una práctica estándar.

En segundo lugar, como dije en mi comentario, muchas de las interrupciones se llaman INTG1 y otros nombres crípticos, estos también tienen un propósito. En los diagramas de circuito NO es una buena convención nombrar sus líneas y, de manera tan vergonzosa, satura el diagrama y perjudica la legibilidad. Toda la verbosidad se maneja en la documentación. Y dado que todos los diagramas de cableado / circuito tienen estos nombres cortos para líneas de interrupción, las interrupciones en sí mismas también reciben el mismo nombre para mantener la coherencia para el diseñador incorporado desde el diagrama de circuito hasta el código para programarlo.

Un diseñador tiene cierto control sobre esto, pero al igual que cualquier campo / lenguaje nuevo, existen convenciones que se siguen de hardware a hardware, y como tal deberían mantenerse similares en cada lenguaje ensamblador. Puedo ver un fragmento de ensamblaje y ser capaz de obtener la esencia del código sin usar ese conjunto de instrucciones porque se adhieren a una convención, LDA o alguna relación con él, probablemente esté cargando un registro MV probablemente está moviendo algo de algún lado a en otro lugar, no se trata de lo que crees que es bueno o es una práctica de alto nivel, es un lenguaje en sí mismo y, como tal, tiene sus propios estándares y significa que tú, como diseñador, debes seguirlos, a menudo no son tan arbitrarios como ellos parecen.

Te dejo con esto: pedirle a la comunidad integrada que use prácticas detalladas de alto nivel es como pedirles a los químicos que siempre escriban compuestos químicos. El químico los escribe cortos para sí mismos y cualquier otra persona en el campo lo entenderá, pero puede tomar un poco de tiempo para adaptarse.

Jeff Langemeier
fuente
1
Siento que "usaremos nombres crípticos porque eso es lo que hace que la programación de bajo nivel se sienta como tal" y "usaremos nombres crípticos porque esa es la convención para la programación de bajo nivel" son más o menos lo mismo, entonces +1 de mi parte y pensaré en aceptar esto como una variante menos inflamatoria de la que acepté inicialmente .
Roman Starkov
66
+1 para la referencia de los químicos, ya que genera una buena analogía para los diferentes ámbitos de la programación.
44
+1 Tampoco entendí por qué las personas usan nombres cortos y crípticos como "agua" si existe el "DiHydrogenOxyde" mucho más legible
Ingo
6

Una razón por la que usan identificadores cortos crípticos es porque no son crípticos para los desarrolladores. Tienes que darte cuenta de que trabajan con él todos los días y esos nombres son realmente nombres de dominio. Entonces saben de memoria qué significa exactamente TIFR1.

Si un nuevo desarrollador llega al equipo, tendrá que leer las hojas de datos (como lo explicó @KarlBielefeldt) para que se sientan cómodos con ellas.

Creo que su pregunta usó un mal ejemplo porque, de hecho, en ese tipo de códigos fuente generalmente se ven muchos identificadores de criptas innecesarios para cosas que no son de dominio.

Diría que lo hacen principalmente debido a los malos hábitos que existían cuando los compiladores no completaban automáticamente todo lo que escribía.

Alex
fuente
5

Resumen

El inicialismo es un fenómeno generalizado en muchos círculos técnicos y no técnicos. Como tal, no se limita a la programación de bajo nivel. Para la discusión general, vea el artículo de Wikipedia sobre acrónimo . Mi respuesta es específica para la programación de bajo nivel.

Causas de nombres crípticos:

  1. Las instrucciones de bajo nivel están fuertemente tipadas
  2. Necesita empaquetar mucha información de tipo en el nombre de una instrucción de bajo nivel
  3. Históricamente, se prefieren los códigos de un solo carácter para empaquetar la información de tipo.

Soluciones y sus inconvenientes:

  1. Existen esquemas modernos de nombres de bajo nivel que son más consistentes que los históricos.
    • LLVM
  2. Sin embargo, todavía existe la necesidad de empacar mucha información de tipo.
    • Por lo tanto, las abreviaturas crípticas todavía se pueden encontrar en todas partes.
  3. La legibilidad mejorada de línea a línea ayudará a un programador novato de bajo nivel a aprender el idioma más rápido, pero no ayudará a comprender grandes piezas de código de bajo nivel.

Respuesta completa

(A) Los nombres más largos son posibles. Por ejemplo, los nombres de los intrínsecos C ++ SSE2 promedian 12 caracteres en comparación con los 7 caracteres en el mnemónico de ensamblaje. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) La pregunta pasa a: ¿Cuánto tiempo / no críptico necesita uno para obtener instrucciones de bajo nivel?

(C) Ahora analizamos la composición de tales esquemas de nombres. Los siguientes son dos esquemas de nombres para la misma instrucción de bajo nivel:

  • Esquema de nombres # 1: CVTSI2SD
  • Esquema de nombres # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Las instrucciones de bajo nivel siempre se escriben fuertemente. No puede haber ambigüedad, inferencia de tipos, conversión automática de tipos o sobrecarga (reutilización del nombre de la instrucción para significar operaciones similares pero no equivalentes).

(C.2) Cada instrucción de bajo nivel debe codificar mucha información de tipo en su nombre. Ejemplos de información:

  • Familia de arquitectura
  • Operación
  • Argumentos (entradas) y salidas
  • Tipos (entero con signo, entero sin signo, flotante)
  • Precisión (ancho de bits)

(C.3) Si se detalla cada pieza de información, el programa será más detallado.

(C.4) Los esquemas de codificación de tipo utilizados por varios proveedores tenían largas raíces históricas. Como ejemplo, en el conjunto de instrucciones x86:

  • B significa byte (8 bits)
  • W significa palabra (16 bits)
  • D significa dword "palabra doble" (32 bits)
  • Q significa qword "quad-word" (64 bits)
  • DQ significa dqword "doble-quad-word" (128 bits)

Estas referencias históricas no tenían ningún significado moderno, pero aún se mantienen. Un esquema más consistente habría puesto el valor del ancho de bits (8, 16, 32, 64, 128) en el nombre.

Por el contrario, LLVM es un paso correcto en la dirección de la coherencia en las instrucciones de bajo nivel: http://llvm.org/docs/LangRef.html#functions

(D) Independientemente del esquema de nomenclatura de instrucciones, los programas de bajo nivel ya son detallados y difíciles de entender porque se centran en los detalles minuciosos de la ejecución. Cambiar el esquema de nomenclatura de instrucciones mejorará la legibilidad en un nivel de línea a línea, pero no eliminará la dificultad de comprender las operaciones de un gran código.

rwong
fuente
1
La legibilidad mejorada de línea a línea necesariamente tendrá algún impacto en la comprensión de todo el asunto, pero nombrar solo no puede hacerlo trivial, por supuesto.
Roman Starkov
3
Además, es algo fuera de tema, pero CVTSI2SDno lleva más información que ConvertDword2Doubleo ConvInt32ToFloat64, pero este último, aunque más largo, es reconocible al instante, mientras que el primero debe ser descifrado ...
Roman Starkov
2

Los humanos leen y escriben ensamblajes solo ocasionalmente, y la mayoría de las veces es solo un protocolo de comunicación. Es decir, se usa con mayor frecuencia como una representación intermedia basada en texto serializado entre el compilador y el ensamblador. Cuanto más detallada es esta representación, más sobrecarga innecesaria se encuentra en este protocolo.

En el caso de códigos de operación y nombres de registro, los nombres largos realmente dañan la legibilidad. La mnemotecnia corta es mejor para un protocolo de comunicación (entre compilador y ensamblador), y el lenguaje ensamblador es un protocolo de comunicación la mayor parte del tiempo. Los mnemónicos cortos son mejores para los programadores, ya que el código del compilador es más fácil de leer.

SK-logic
fuente
Si necesita ahorrar espacio, ¡simplemente gzip! ... Si no necesita sobrecarga, ¡use un formato binario! Si está utilizando texto, su objetivo es la legibilidad, entonces, ¿por qué no hacer todo lo posible y hacerlo legible correctamente?
Roman Starkov el
2
@romkyns, ¿comprime un protocolo de comunicación basado en texto entre dos procesos locales? Eso es algo nuevo Los protocolos binarios son mucho menos robustos. Es una forma unix: los protocolos basados ​​en texto están ahí para una legibilidad ocasional . Son legibles lo suficiente.
SK-logic
Derecha. Su premisa es que leo y escribo los nombres de estos registros o instrucciones CIL lo suficientemente poco como para que la sobrecarga importe. Pero piénsalo; se usan con tanta frecuencia como cualquier método extraño o nombre de variable en cualquier otro lenguaje de programación mientras está programando . ¿Es tan raro que importen los pocos bytes adicionales?
Roman Starkov el
1
Respeto su derecho a tener un gusto diferente en cuanto a la longitud de los nombres, pero ¿realmente nombra métodos y locales en sus compiladores, cosas crípticas como TIFR, o tienden a contener palabras completas?
Roman Starkov el
1
No veo ninguna diferencia que sea relevante para la compensación legible vs. corta. Los veo como diferentes, por supuesto, al igual que las variables son diferentes a las funciones que son diferentes a los tipos. Simplemente no veo por qué los códigos de operación y los nombres de registro se benefician de ser extremadamente cortos hasta el punto de tener que consultar la documentación de cada uno nuevo antes de tener alguna idea de lo que hace. Su único argumento hasta ahora es el almacenamiento eficiente, si no me equivoco. ¿ Realmente lo dices en serio ? ... ¿O tienes otras razones?
Roman Starkov
1

Sobre todo es idiomático. Como @TMN dice en otra parte, así como no escribes import JavaScriptObjectNotationo import HypertextTransferProtocolLibraryen Python, no escribes Timer1LowerHalf = 0xFFFFen C. Parece igualmente ridículo en su contexto. Todos los que necesitan saber ya lo saben.

La resistencia al cambio puede surgir, en parte, del hecho de que algunos proveedores de compiladores de C para sistemas integrados se desvían del estándar y la sintaxis del lenguaje para implementar funciones más útiles para la programación integrada. Esto significa que no siempre puede usar la función de autocompletar de su IDE favorito o editor de texto al escribir código de bajo nivel, porque estas personalizaciones anulan su capacidad de analizar código. De ahí la utilidad de nombres de registro cortos, macros y constantes.

Por ejemplo, el compilador C de HiTech incluía una sintaxis especial para las variables que necesitaban tener una posición especificada por el usuario en la memoria. Puedes declarar:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Ahora, el único IDE existente que analizará esto es el propio IDE de HiTech ( HiTide ). En cualquier otro editor, tendrá que escribirlo manualmente, desde la memoria, cada vez. Esto envejece muy rápido.

Luego también está el hecho de que cuando usa herramientas de desarrollo para inspeccionar registros, a menudo se muestra una tabla con varias columnas (nombre de registro, valor en hexadecimal, valor en binario, último valor en hexadecimal, etc.). Los nombres largos significan que debe expandir la columna del nombre a 13 caracteres para ver la diferencia entre dos registros y jugar a "detectar la diferencia" en docenas de líneas de palabras repetidas.

Esto puede sonar como pequeñas tonterías tontas, pero ¿no están todas las convenciones de codificación diseñadas para reducir la fatiga visual, disminuir el tipeo superfluo o abordar una de las millones de pequeñas quejas?

desviarse
fuente
2
Todos tus argumentos tienen sentido. Entiendo completamente todos esos puntos. Sin embargo, ¿no crees que exactamente lo mismo se aplica al código de alto nivel? También necesita ver una tabla de locales en una función C #. El contexto es subjetivo y File.ReadAllBytestambién puede parecer ridículamente largo para alguien acostumbrado fread. Entonces ... ¿por qué tratar el código de alto y bajo nivel de manera diferente ?
Roman Starkov
@romkyns: entiendo su punto de vista, pero no creo que en realidad no tratemos el código de alto nivel de manera muy diferente. Las abreviaturas están bien en muchos contextos de alto nivel, simplemente no nos damos cuenta porque estamos más acostumbrados a la abreviatura o cualquier esquema que la acompañe. Cuando realmente escribo funciones o creo variables en código de bajo nivel, utilizo buenos nombres descriptivos. Pero cuando me refiero a un registro, me alegra poder echar un vistazo a un revoltijo de letras y números y pensar rápidamente "T = temporizador, IF = indicador de interrupción, 1 = primer registro". Es casi como la química orgánica en ese sentido: P
detly
@romkyns - Además, en un sentido puramente práctico, creo que la diferencia entre una tabla de registros en el desarrollo de IDE y aplicación de algunos microprocesadores en C # es la siguiente: una tabla de registra hasta podría ser: Timer1InterruptFlag, Timer2InterruptFlag, ..., Timer9InterruptFlag, IOPortAToggleMask, IOPortBToggleMask, etc x100. En un lenguaje de nivel superior, usarías variables que difieren mucho más ... o usarías más estructura. Timer1InterruptFlages un 75% de ruido irrelevante en comparación con T1IF. No creo que cree una gran lista de variables en C # que apenas difieran así.
detly
1
@romkyns: lo que quizás no sepa es el hecho de que ha habido un cambio hacia lo que usted describe. Los compiladores recientes de Microchip vienen con bibliotecas que son mucho más detalladas y descriptivas que solo registros, por ejemplo. UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200). Pero todavía son increíblemente torpes e implican mucha indirección e ineficiencia. Intento usarlos siempre que sea posible, pero la mayoría de las veces, envuelvo la manipulación del registro en mis propias funciones y la llamo desde la lógica de nivel superior.
detly
@detly: el compilador CCS tenía tales métodos, y algunos otros procesadores lo hacen. Generalmente no me gustan. La especificación de registro es suficiente para escribir código que usa los registros y es suficiente para permitir que alguien lea el código que usa registros para ver qué hacen esos registros. Si el acto de escribir un valor de N en un preescalar de hardware establece el período en N + 1 (bastante común), el significado correcto de set_prescalar(TMR4,13);es en mi humilde opinión mucho menos claro de lo que sería TMR4->PSREG=12;. Incluso si uno mira el manual del compilador para averiguar qué hace el primer código, probablemente todavía tendrá que ...
supercat
1

Me sorprende que nadie haya mencionado la pereza y que no se discutan otras ciencias. Mi trabajo diario como programador me muestra que las convenciones de nomenclatura para cualquier tipo de variable en un programa están influenciadas por tres aspectos diferentes:

  1. La formación científica del programador.
  2. Las habilidades de programación del programador.
  3. El entorno del programador.

Creo que no sirve de nada discutir sobre programación de bajo o alto nivel. Al final, siempre se puede precisar a los tres aspectos anteriores.


Una explicación del primer aspecto: muchos "programadores" no son programadores en primer lugar. Son matemáticos, físicos, biólogos o incluso psicólogos o economistas, pero muchos de ellos no son informáticos. La mayoría de ellos tienen sus propias palabras clave y abreviaturas específicas de dominio que puede ver en sus "convenciones" de nombres. A menudo están atrapados en su dominio y usan esas abreviaturas conocidas sin pensar en la legibilidad o las guías de codificación.

Una explicación del segundo aspecto: como la mayoría de los programadores no son informáticos, sus habilidades de programación son limitadas. Es por eso que a menudo no les importan las convenciones de codificación, sino más bien las convenciones específicas de dominio como se indica como primer aspecto. Además, si no tiene las habilidades de un programador, no tiene la comprensión de las convenciones de codificación. Creo que la mayoría de ellos no ven la necesidad urgente de escribir un código comprensible. Es como fuego y olvidar.

Una explicación del tercer aspecto: es poco probable que rompa con las convenciones de su entorno, que pueden ser códigos antiguos que debe admitir, estándares de codificación de su empresa (administrados por economistas a quienes no les importa la codificación) o el dominio al que pertenece. Si alguien comenzó a usar nombres crípticos y usted tiene que apoyarlo a él o su código, es poco probable que cambie los nombres crípticos. Si no hay estándares de codificación en su empresa, apuesto a que casi todos los programadores escribirán sus propios estándares. Y por último, si está rodeado de usuarios de dominio, no comenzará a escribir otro idioma del que usan.

wagnerpeer
fuente
nadie ha mencionado la pereza , tal vez eso es porque esto no es relevante aquí. Y que otras ciencias no se discuten, oh, eso es fácil: este sitio no está para discusión . Es para preguntas y respuestas
mosquito
La pereza es una razón legítima. Casi todos los programadores son personas perezosas (de lo contrario, ¡haríamos todo manualmente ooo!).
Thomas Eding