Quali sono alcune strategie per comprendere la semantica delle variabili degli algoritmi?

why the drastic difference in engineering vs. data structure code presentation?

È una sfortunata intersezione tra matematica e informatica.

In matematica, ogni variabile è spesso indicata con un singolo simbolo. Ci sono molte ragioni per questo; tra questi è quello di evitare la confusione di associatività e ambiguità dei nomi di variabili multi-lettera.

Ad esempio, quando si scrive abc in una formula, non è ambiguo se lo si comprende supponendo che ciascuno di a , b , c sia il proprio simbolo, invece di abc essendo una singola variabile.

Nel frattempo, in matematica si lotta per la coerenza. Ogni simbolo, come x , y , double-struck ℝ , ha un significato predefinito; l'uso improprio non è consentito.

Sfortunatamente non c'è una tale coerenza seguita nella programmazione del software.

Per quanto riguarda i materiali didattici, sarebbe semplice per gli editor fare una ricerca-sostituzione per convertire i nomi di variabili a lettera singola in nomi più significativi. L'ambiente di sviluppo integrato (IDE) con il supporto del refactoring può spesso farlo con semplici comandi. Come programmatore, puoi fare lo stesso con il codice sorgente che scrivi.

What are some strategies for learning such systems

Se ti riferisci alla domanda sull'apprendimento degli algoritmi e delle strutture dati, questa è sfortunatamente una domanda troppo ampia.

Diverse persone hanno stili diversi, ecco perché ottieni differenze di stile. Le persone hanno anche diversi stili di apprendimento.

Un modo di apprendere algoritmi che funziona per alcune persone è riprodurre l'algoritmo da solo, a poco a poco, con parole tue. In questo modo puoi sostituire nomi di variabili meno significativi con quelli significativi.

Un semplice motivo per x, y, z viene dal passato. Una volta abbiamo usato le schede perforate e dovevamo essere il più concisi possibile durante la codifica. Questa abitudine esiste ancora poiché i nomi lunghi hanno un alto rischio di errori di battitura e si trascorre più tempo a digitare. Quindi da un punto di vista economico questo è comprensibile.

Tuttavia, quando si guardano i tempi di manutenzione del codice, questa abitudine diventa sempre più antieconomica. Comprendere il codice con nomi comprensibili è molto più semplice del codice con nomi criptici (come hai notato). Inoltre ogni IDE moderno offre il completamento del codice che rende facile l'uso di un nome lungo in primo luogo un riutilizzo che.

Ora, quando si tratta di refactoring, le cose possono diventare complicate. Sostituire i nomi criptici con quelli leggibili è solo un primo ma importante passo. Se hai un buon IDE puoi supportarlo riconoscendo i token nell'ambito del tuo codice per sostituire quelli giusti. Quando si dà il nome giusto alle cose, si impara anche sul loro scopo. O viceversa (meglio), una volta decifrato il significato di una variabile / funzione, dargli un nome significativo.

Btw .: Molto tempo fa ero nella situazione in cui ho ereditato un pezzo così grande (FORTRAN) di codice. L'ho fatto creando una copia di ogni file uno per uno, riscrivendolo leggibile loop by loop. Questo è stato un sacco di lavoro, ma ripagato immediatamente. Quanto sarei stato più felice di quei tempi se Git fosse già esistito? Probabilmente avrei fluttuato 1 cm sopra il pavimento per tutto il tempo xD