Ci deve essere utilizzato molto buone ragioni per mantenere l'istruzione / registrare i nomi brevi. Questi motivi non si applicano più, ma i nomi criptici brevi sono ancora molto comuni nella programmazione di basso livello.

Perchè è questo? È solo perché le vecchie abitudini sono difficili da rompere o ci sono ragioni migliori?

Per esempio:

• Atmel ATMEGA32U2 (2010?): TIFR1(Anziché TimerCounter1InterruptFlag), ICR1H(anziché InputCapture1High), DDRB(anziché DataDirectionPortB), ecc.
• Set di istruzioni CLR .NET (2002): bge.s(anziché branch-if-greater-or-equal.short), ecc.

I nomi più lunghi e non criptici non sono più facili da lavorare?

Per rispondere e votare, ti preghiamo di considerare quanto segue. Molte delle possibili spiegazioni suggerite qui si applicano ugualmente alla programmazione di alto livello, e tuttavia il consenso, in linea di massima, è di usare nomi non criptici costituiti da una o due parole (esclusi gli acronimi comunemente intesi).

Inoltre, se il tuo argomento principale riguarda lo spazio fisico su un diagramma cartaceo , tieni presente che questo non si applica assolutamente al linguaggio assembly o CIL, inoltre apprezzerei se mi mostrassi un diagramma in cui i nomi concisi si adattano ma quelli leggibili peggiorano il diagramma . Dall'esperienza personale in una società di semiconduttori senza fabbisogno, i nomi leggibili si adattano perfettamente e risultano in diagrammi più leggibili.

Qual è la cosa principale che differisce nella programmazione di basso livello rispetto ai linguaggi di alto livello che rende desiderabili i nomi criptici concisi nella programmazione di basso livello ma non di alto livello?

Il motivo per cui il software usa quei nomi è perché i fogli dati usano quei nomi. Dato che il codice a quel livello è molto difficile da capire senza il foglio dati comunque, rendere estremamente utili i nomi delle variabili che non è possibile cercare.

Ciò solleva la questione del perché i fogli dati utilizzino nomi brevi. Ciò è probabilmente dovuto al fatto che spesso devi presentare i nomi in tabelle come questa in cui non hai spazio per identificatori di 25 caratteri:

Inoltre, cose come schemi, diagrammi a spillo e serigrafie PCB sono spesso molto angusti per lo spazio.

Legge di Zipf

Tu stesso puoi osservare guardando questo stesso testo che la lunghezza e la frequenza delle parole sono, in generale, inversamente correlate. Le parole che vengono utilizzati molto frequentemente, come it, a, but, you, e andsono molto brevi, mentre le parole che vengono utilizzati meno spesso piace observe, comprehensione verbositysono più lunghe. Questa relazione osservata tra frequenza e lunghezza si chiama Legge di Zipf .

Il numero di istruzioni nell'insieme di istruzioni per un dato microprocessore di solito numera in dozzine o centinaia. Ad esempio, il set di istruzioni Atmel AVR sembra contenere un centinaio di istruzioni distinte (non ho contato), ma molte di queste sono variazioni su un tema comune e hanno mnemonici molto simili. Ad esempio, le istruzioni di moltiplicazione includono MUL, MULS, MULSU, FMUL, FMULS e FMULSU. Non è necessario esaminare l'elenco delle istruzioni molto a lungo prima di avere l'idea generale che le istruzioni che iniziano con "BR" sono rami, le istruzioni che iniziano con "LD" sono carichi, ecc. Lo stesso vale per le variabili: anche i processori complessi forniscono solo un numero limitato di posizioni per memorizzare valori: registri delle condizioni, registri per uso generale, ecc.

Poiché ci sono così poche istruzioni e poiché i nomi lunghi richiedono più tempo per essere letti, ha senso dar loro nomi brevi. Al contrario, linguaggi di livello superiore consentono ai programmatori di creare un numero enorme di funzioni, metodi, classi, variabili e così via. Ognuno di questi sarà usato molto meno frequentemente della maggior parte delle istruzioni di assemblaggio e nomi più lunghi e più descrittivi sono sempre più importanti per fornire ai lettori (e agli scrittori) informazioni sufficienti per capire cosa sono e cosa fanno.

Inoltre, i set di istruzioni per processori diversi usano spesso nomi simili per operazioni simili. La maggior parte dei set di istruzioni include operazioni per ADD, MUL, SUB, LD, ST, BR, NOP, e se non usano quei nomi esatti di solito usano nomi molto vicini. Dopo aver appreso i mnemonici per un set di istruzioni, non ci vuole molto tempo per adattarsi ai set di istruzioni per altri dispositivi. Così i nomi che potrebbero sembrare "criptica" per voi sono circa come familiare come parole come and, ore notper i programmatori che sono esperti nell'arte della programmazione a basso livello. Penso che la maggior parte delle persone che lavorano a livello di assemblea ti direbbero che imparare a leggere il codice non è una delle maggiori sfide nella programmazione di basso livello.

In generale

La qualità della denominazione non riguarda solo i nomi descrittivi, ma deve anche considerare altri aspetti e ciò porta a raccomandazioni come:

• più globale è l'ambito, più descrittivo dovrebbe essere il nome
• più spesso viene utilizzato, più breve dovrebbe essere il nome
• lo stesso nome dovrebbe essere usato in tutti i contesti per la stessa cosa
• cose diverse dovrebbero avere nomi diversi anche se il contesto è diverso
• le variazioni dovrebbero essere facilmente rilevate
• ...

Si noti che queste raccomandazioni sono contrastanti.

Istruzioni mnemoniche

Come programmatore di linguaggio assembly, usare short-branch-if-greater-or-equalfor bge.smi dà la stessa impressione di quando vedo, come programmatore Algol che fa geometria computazionale, 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-POINTSinvece di dx := p2.x - p1.x. Non riesco proprio a concordare sul fatto che i primi siano più leggibili nei contesti che mi interessano.

Registra i nomi

Scegli il nome ufficiale dalla documentazione. La documentazione prende il nome dal disegno. Il design utilizza molti formati grafici in cui i nomi lunghi non sono adeguati e il team di progettazione vivrà con quei nomi per mesi, se non per anni. Per entrambi i motivi, non useranno "Flag di interruzione del primo contatore del timer", lo abbrevieranno nel loro schema e quando parlano. Lo sanno e usano abbreviazioni sistematiche come in TIFR1modo che ci siano meno possibilità di confusione. Un punto qui è che TIFR1non è un'abbreviazione casuale, è il risultato di uno schema di denominazione.

A parte le ragioni delle "vecchie abitudini", il codice Legacy che è stato scritto 30 anni fa ed è ancora in uso è molto comune. Nonostante ciò che pensano alcune persone meno esperte, il refactoring di questi sistemi in modo che appaiano belli ha un costo molto elevato per un piccolo guadagno e non è commercialmente praticabile.

I sistemi integrati vicini all'hardware e che accedono ai registri tendono a utilizzare etichette uguali o simili a quelle utilizzate nelle schede tecniche dell'hardware, per ottime ragioni. Se il registro è chiamato XYZZY1 nelle schede hardware, ha senso che la variabile che lo rappresenta sia probabilmente XYZZY1, o se il programmatore stava passando una buona giornata, RegXYZZY1.

Per quanto riguarda il bge.s, è simile all'assemblatore - alle poche persone che hanno bisogno di conoscerlo i nomi più lunghi sono meno leggibili. Se non riesci a farti andare in giro bge.se pensi branch-if-greater-or-equal.shortche farà la differenza, stai semplicemente giocando con il CLR e non lo sai.

L'altro motivo per cui vedrai nomi di variabili brevi è dovuto alla diffusa diffusione di abbreviazioni all'interno del dominio a cui il software è destinato.

In breve: sono attesi nomi di variabili abbreviati brevi che riflettono un'influenza esterna come norme di settore e schede tecniche hardware. Nomi variabili abbreviati interni al software sono normalmente meno desiderabili.

Ci sono così tante idee diverse qui. Non posso accettare nessuna delle risposte esistenti come la risposta: in primo luogo, ci sono probabilmente molti fattori che contribuiscono a questo, e in secondo luogo, non può assolutamente sapere quale è quello più significativo.

Quindi ecco un riassunto delle risposte pubblicate da altri qui. Sto pubblicando questo come CW e la mia intenzione è di contrassegnarlo come accettato. Modifica se ho perso qualcosa. Ho cercato di riformulare ogni idea per esprimerla in modo conciso ma chiaro.

Quindi perché gli identificatori brevi criptici sono così comuni nella programmazione di basso livello?

• Perché molti di loro sono abbastanza comuni nel rispettivo dominio da giustificare un nome molto breve. Ciò peggiora la curva di apprendimento, ma è un compromesso utile data la frequenza d'uso.
• Perché di solito c'è un piccolo set di possibilità che è stato risolto (il programmatore non può aggiungere al set).
• Perché la leggibilità è una questione di abitudine e pratica. branch-if-greater-than-or-equal.shortè inizialmente più leggibile di bge.s, ma con un po 'di pratica la situazione si inverte.
• Perché spesso devono essere digitati per intero, a mano, perché le lingue di basso livello spesso non sono dotate di potenti IDE che hanno un buon completamento automatico o che a / c non è affidabile.
• Perché a volte è desiderabile inserire molte informazioni nell'identificatore e un nome leggibile sarebbe inaccettabilmente lungo anche per standard di alto livello.
• Perché è quello che gli ambienti di basso livello sono stati storicamente. L'abitudine alla rottura richiede uno sforzo consapevole, corre il rischio di infastidire coloro che amavano i vecchi modi e deve essere giustificato come utile. Attenersi al modo stabilito è "predefinito".
• Perché molti di loro hanno origine altrove, come schemi e schede tecniche. Questi, a loro volta, sono influenzati da vincoli di spazio.
• Perché le persone incaricate di nominare le cose non hanno mai nemmeno preso in considerazione la leggibilità o non si rendono conto che stanno creando un problema o sono pigre.
• Perché in alcuni casi i nomi sono diventati parte di un protocollo per lo scambio di dati, come l'uso del linguaggio assembly come rappresentazione intermedia da parte di alcuni compilatori.
• Perché questo stile è immediatamente riconoscibile come di basso livello e quindi sembra interessante per i geek.

Personalmente ritengo che alcuni di questi non contribuiscano effettivamente ai motivi per cui un sistema appena sviluppato avrebbe scelto questo stile di denominazione, ma ho ritenuto che sarebbe sbagliato filtrare alcune idee in questo tipo di risposta.

Ho intenzione di gettare il mio cappello in questo casino.

Convenzioni e standard di codifica di alto livello non sono gli stessi di standard e pratiche di codifica di basso livello. Sfortunatamente, la maggior parte di questi sono ritardi dal codice legacy e vecchi processi di pensiero.

Alcuni, tuttavia, servono a uno scopo. Sicuramente BranchGreaterThan sarebbe molto più leggibile di BGT , ma ora c'è una convenzione lì, è un'istruzione e come tale ha guadagnato un po 'di trazione negli ultimi 30 anni di utilizzo come standard. Perché hanno iniziato con questo, probabilmente un limite di larghezza di carattere arbitrario per istruzioni, variabili e simili; perché lo tengono, è uno standard. Questo standard equivale a usare int come identificatore, sarebbe più leggibile usare Integer in tutti i casi, ma è necessario per chiunque stia programmando da più di qualche settimana ... no. Perché? Perché è una pratica standard.

In secondo luogo, come ho detto nel mio commento, molti degli interrupt sono chiamati INTG1 e altri nomi criptici, anche questi hanno uno scopo. Negli schemi circuitali NON è una buona convenzione nominare le linee e così verbalmente ingombra lo schema e fa male alla leggibilità. Tutta la verbosità è gestita nella documentazione. E poiché tutti gli schemi di cablaggio / circuito hanno questi nomi brevi per le linee di interruzione, anche gli stessi interruttori hanno lo stesso nome di mantenere la coerenza per il progettista incorporato dallo schema del circuito fino al codice per programmarlo.

Un progettista ha un certo controllo su questo, ma come ogni campo / nuovo linguaggio ci sono convenzioni che seguono da hardware a hardware e come tali dovrebbero rimanere simili in ogni linguaggio di assemblaggio. Posso guardare uno snippet di assembly ed essere in grado di ottenere l'essenza del codice senza mai usare quell'insieme di istruzioni perché aderiscono a una convenzione, LDA o qualche relazione ad esso è probabilmente caricando un registro MV sta probabilmente spostando qualcosa da qualche parte a da qualche altra parte, non si tratta di ciò che pensi sia bello o è una pratica di alto livello, è un linguaggio a sé stante e come tale ha i suoi standard e significa che tu come il designer dovrebbe seguire, questi spesso non sono così arbitrari come sembrano.

Ti lascio con questo: chiedere alla comunità incorporata di usare pratiche verbose di alto livello è come chiedere ai chimici di scrivere sempre composti chimici. Il chimico li scrive per sé e chiunque altro sul campo lo capirà, ma potrebbe essere necessario un po 'di tempo prima che un nuovo arrivato si adegui.

Uno dei motivi per cui usano identificatori brevi criptici è perché non sono criptici per gli sviluppatori. Devi capire che ci lavorano ogni giorno e quei nomi sono davvero nomi di dominio. Quindi sanno a memoria cosa significa esattamente TIFR1.

Se un nuovo sviluppatore arriva nel team, dovrà leggere i fogli dati (come spiegato da @KarlBielefeldt) in modo che si sentano a proprio agio con quelli.

Credo che la tua domanda abbia usato un cattivo esempio perché in effetti su quel tipo di codici sorgente di solito vedi molti identificatori di cripta non necessari per cose non di dominio.

Direi principalmente che lo fanno a causa delle cattive abitudini che esistevano quando i compilatori non completavano automaticamente tutto ciò che scrivevi.

Sommario

L'inizialismo è un fenomeno pervasivo in molti ambienti tecnici e non tecnici. Pertanto, non si limita alla programmazione di basso livello. Per la discussione generale, vedere l'articolo di Wikipedia su Acronimo . La mia risposta è specifica per la programmazione di basso livello.

Cause di nomi criptici:

1. Le istruzioni di basso livello sono fortemente tipizzate
2. È necessario inserire molte informazioni sul tipo nel nome di un'istruzione di basso livello
3. Storicamente, i codici a carattere singolo sono preferiti per impacchettare le informazioni sul tipo.

Soluzioni e loro svantaggi:

1. Esistono schemi di denominazione moderni di basso livello che sono più coerenti di quelli storici.
   • LLVM
2. Tuttavia, esiste ancora la necessità di comprimere molte informazioni sul tipo.
   • Pertanto, le abbreviazioni criptiche possono ancora essere trovate ovunque.
3. Una migliore leggibilità da linea a linea aiuterà un programmatore di basso livello principiante a imparare la lingua più velocemente, ma non aiuterà a comprendere grandi parti di codice di basso livello.

Risposta completa

(A) Sono possibili nomi più lunghi. Ad esempio, i nomi degli intrinseci C ++ SSE2 hanno una media di 12 caratteri rispetto ai 7 caratteri nell'assembly mnemonico. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) La domanda passa quindi a: Quanto tempo / non criptico è necessario ottenere da istruzioni di basso livello?

(C) Ora analizziamo la composizione di tali schemi di denominazione. Di seguito sono riportati due schemi di denominazione per la stessa istruzione di basso livello:

• Schema di denominazione n. 1: CVTSI2SD
• Schema di denominazione n. 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Le istruzioni di basso livello sono sempre fortemente tipizzate. Non ci possono essere ambiguità, inferenza del tipo, conversione automatica del tipo o sovraccarico (riutilizzo del nome dell'istruzione per indicare operazioni simili ma non equivalenti).

(C.2) Ogni istruzione di basso livello deve codificare molte informazioni sul tipo nel suo nome. Esempi di informazioni:

• Famiglia di architettura
• operazione
• Argomenti (input) e output
• Tipi (intero con segno, intero senza segno, virgola mobile)
• Precisione (larghezza bit)

(C.3) Se ogni informazione viene precisata, il programma sarà più dettagliato.

(C.4) Gli schemi di codifica del tipo utilizzati da vari fornitori avevano radici storiche lunghe. Ad esempio, nel set di istruzioni x86:

• B significa byte (8 bit)
• W significa parola (16 bit)
• D significa dword "doppia parola" (32 bit)
• Q significa qword "quad-word" (64 bit)
• DQ significa dqword "double-quad-word" (128 bit)

Questi riferimenti storici non avevano alcun significato moderno, ma rimangono ancora in circolazione. Uno schema più coerente avrebbe inserito il valore della larghezza in bit (8, 16, 32, 64, 128) nel nome.

Al contrario, LLVM è un passo giusto nella direzione della coerenza nelle istruzioni di basso livello: http://llvm.org/docs/LangRef.html#functions

(D) Indipendentemente dallo schema di denominazione delle istruzioni, i programmi di basso livello sono già dettagliati e difficili da capire perché si concentrano sui minimi dettagli dell'esecuzione. La modifica dello schema di denominazione delle istruzioni migliorerà la leggibilità da un livello riga a riga, ma non eliminerà la difficoltà di comprendere le operazioni di un grosso codice.

Gli umani leggono e scrivono gli assemblaggi solo occasionalmente e il più delle volte è solo un protocollo di comunicazione. Vale a dire, viene spesso utilizzato come rappresentazione seriale basata su testo intermedia tra compilatore e assemblatore. Più dettagliata è questa rappresentazione, maggiore è il sovraccarico inutile in questo protocollo.

Nel caso di codici operativi e nomi di registro, i nomi lunghi in realtà danneggiano la leggibilità. I mnemonici brevi sono migliori per un protocollo di comunicazione (tra compilatore e dicembre) e il linguaggio assembly è un protocollo di comunicazione per la maggior parte del tempo. I mnemonici brevi sono migliori per i programmatori, poiché il codice del compilatore è più facile da leggere.

Principalmente è idiomatico. Come dice @TMN altrove, proprio come non scrivi import JavaScriptObjectNotationo import HypertextTransferProtocolLibraryin Python, non scrivi Timer1LowerHalf = 0xFFFFin C. Sembra altrettanto ridicolo nel contesto. Tutti quelli che hanno bisogno di sapere lo sanno già.

La resistenza al cambiamento potrebbe derivare, in parte, dal fatto che alcuni produttori di compilatori C per sistemi embedded si discostano dallo standard linguistico e dalla sintassi per implementare funzionalità più utili alla programmazione integrata. Ciò significa che non è sempre possibile utilizzare la funzione di completamento automatico del proprio IDE o editor di testo preferito durante la scrittura di codice di basso livello, poiché queste personalizzazioni vanificano la loro capacità di analizzare il codice. Da qui l'utilità di nomi di registro brevi, macro e costanti.

Ad esempio, il compilatore C di HiTech includeva una sintassi speciale per le variabili che dovevano avere una posizione specificata dall'utente in memoria. Potresti dichiarare:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Ora l'unico IDE esistente che analizzerà questo è l'IDE di HiTech ( HiTide ). In qualsiasi altro editor, dovrai scriverlo manualmente, dalla memoria, ogni volta. Questo invecchia molto rapidamente.

Quindi c'è anche il fatto che quando usi gli strumenti di sviluppo per ispezionare i registri, avrai spesso una tabella visualizzata con diverse colonne (nome del registro, valore in esadecimale, valore in binario, ultimo valore in esadecimale, ecc.). I nomi lunghi significano che devi espandere la colonna del nome a 13 caratteri per vedere la differenza tra due registri e giocare "individuare la differenza" attraverso dozzine di righe di parole ripetute.

Questi potrebbero sembrare piccoli cavilli stupidi, ma non tutte le convenzioni di codifica sono progettate per ridurre l'affaticamento degli occhi, ridurre la digitazione superflua o rispondere a uno qualsiasi dei milioni di altri piccoli reclami?

Sono sorpreso che nessuno abbia menzionato la pigrizia e che altre scienze non siano discusse. Il mio lavoro quotidiano come programmatore mi mostra che le convenzioni di denominazione per qualsiasi tipo di variabile in un programma sono influenzate da tre diversi aspetti:

1. Il background scientifico del programmatore.
2. Le capacità di programmazione del programmatore.
3. L'ambiente del programmatore.

Penso che sia inutile discutere di programmazione di basso o alto livello. Alla fine può sempre essere fissato ai primi tre aspetti.

Una spiegazione del primo aspetto: molti "programmatori" non sono programmatori in primo luogo. Sono matematici, fisici, biologi o persino psicologi o economisti, ma molti di loro non sono informatici. La maggior parte di essi ha le proprie parole chiave e abbreviazioni specifiche del dominio che puoi vedere nelle loro "convenzioni" di denominazione. Sono spesso intrappolati nel loro dominio e usano quelle abbreviazioni note senza pensare alla leggibilità o alle guide alla programmazione.

Una spiegazione del secondo aspetto: poiché la maggior parte dei programmatori non è un informatico, le sue capacità di programmazione sono limitate. Ecco perché spesso non si preoccupano delle convenzioni di codifica, ma di più sulle convenzioni specifiche del dominio, come indicato come primo aspetto. Inoltre, se non hai le competenze di un programmatore, non hai la comprensione delle convenzioni di codifica. Penso che molti di loro non vedano l'urgente necessità di scrivere un codice comprensibile. È come il fuoco e dimentica.

Una spiegazione del terzo aspetto: è improbabile frenare con le convenzioni del tuo ambiente che possono essere il vecchio codice che devi supportare, gli standard di codifica della tua azienda (gestiti da economisti che non si preoccupano della codifica) o il dominio a cui appartieni. Se qualcuno ha iniziato a utilizzare i nomi criptici e devi supportare lui o il suo codice, è improbabile che cambino i nomi criptici. Se non ci sono standard di codifica nella tua azienda, scommetto che quasi ogni programmatore scriverà il proprio standard. E infine se sei circondato da utenti di dominio non inizierai a scrivere un altro linguaggio di quello che usano.