Lo scopo del codice è "idiomatico" per ridurre le spese cognitive?

Sto cercando di spiegare a qualcuno che il modo in cui hanno scritto il codice rende difficile da capire, e se lo refactoring è più facile da leggere. Questo stile di codice a cui sto guidando è comunemente chiamato "codice idiomatico".

Ma la frase codice idiomatico porta con sé un bagaglio di correttezza morale , che non è un grande motivatore per indurre le persone a cambiare il loro stile di programmazione. Un modo più positivo per dirlo è il codice che segue lo stile comune, ma per un pensatore critico che si presenta come ragionamento della mentalità del gregge.

Il modo in cui mi è venuta in mente di spiegare questa idea in un modo che motiva le persone a cambiare il loro codice è:

• scrivere il codice in modo tale da ridurre il sovraccarico cognitivo del lettore (ad es. non ricordo se questo è il primo tipo di vettore - o il 5o tipo di vettore)
• codice che semplifica la comprensione dell'intento (ad es. a cosa serve questo vettore?)

(A parte, sono consapevole che il libro The Joy of Clojure, prima della sua prima pubblicazione, aveva la bozza del titolo Idiomatic Clojure. Quindi sembrerebbe una ragione per rendere il codice "idiomatico", per "portare gioia" al lettore ).

La mia domanda è: lo scopo del codice è "idiomatico" per ridurre le spese cognitive?

Primo, non sono sicuro che ci sia una sorta di "correttezza morale" nel termine "idiomatica". La semplice definizione del dizionario è semplicemente

peculiare o caratteristico di una particolare lingua o dialetto: il francese idiomatico.

Sì, il codice idiomatico generalmente riduce l'overhead cognitivo, in particolare nelle definizioni di interfaccia in cui le librerie standard e tutte le librerie di terze parti di cui il progetto necessita sono (praticamente) tutte idiomatiche.

Come punto di vendita, tuttavia, mi concentrerei su ciò che riduce il sovraccarico cognitivo per te. Ai programmatori è più facile individuare errori perché non stanno tentando di svelare il codice scritto in uno stile unico per capire dove è sottilmente da uno o gestire male un caso limite. Rende più facile rivedere il codice di altre persone, il che rende più probabile che il team effettuerà revisioni reali che identificano problemi reali anziché discutere sulla sintassi.

Oltre a ridurre il sovraccarico cognitivo, il codice idiomatico è generalmente un codice più efficiente. La maggior parte dei modi di dire in una lingua particolare si evolve perché la lingua è progettata per affrontare i problemi in un modo particolare. I compilatori o gli interpreti che stai utilizzando focalizzeranno le loro ottimizzazioni sul codice idiomatico. Se usi un linguaggio in cui la ricorsione è il modo idiomatico di strutturare un pezzo di codice, ad esempio, puoi essere quasi certo che il tuo compilatore implementa la ricorsione della coda. Se usi una lingua in cui la ricorsione non è idiomatica, è molto meno probabile. È improbabile che la ricorsione della coda non possa essere implementata ovunque, ma la maggior parte degli autori di compilatori non si concentrerà su cose che non accadono comunemente.

Non sono sicuro di dove tu abbia l'idea che gli idiomi abbiano connotazioni morali. Gli idiomi sono solo un modo per esprimere le cose. Sono schemi su una scala più ampia di singole parole o frasi.

Se ti dicessi che bisogna ululare con i lupi, non sapresti cosa volevo dire, anche se si tratta di un noto linguaggio tedesco. Se, OTOH, ti avessi detto, quando sei a Roma, fai come fanno i romani, sapresti immediatamente di cosa sto parlando, perché ho usato il giusto linguaggio inglese.

I linguaggi del computer non sono diversi.

In realtà, un nome alternativo per "idioma" nel mondo della programmazione è "modello di implementazione". Questo mette in relazione l'idea con i motivi, che proviene dall'architetto (mattoni e malta non bit e byte) Christopher Alexander. La maggior parte dei programmatori è a conoscenza dei modelli di progettazione, alcuni conoscono i modelli di architettura, che sono modelli su una scala più ampia dei modelli di progettazione. I modi di dire sono schemi su una scala più piccola dei modelli di progettazione.

Molte lingue si prestano intenzionalmente a uno stile particolare. Il codice scritto in quello stile è ciò che è idiomatico. Se guardi oltre il fatto circostanziato che la scelta dell'ambiente di runtime restringe la scelta delle lingue disponibili, dovresti scegliere le lingue perché il problema a portata di mano è facile da esprimere nei particolari idiomi di una lingua.

La maggior parte delle persone però non lo capisce. Ad esempio, molti programmatori Java si sforzano di mantenere lo stesso stile quando devono scrivere JavaScript (avrebbero potuto scrivere Java e averlo compilato in modo incrociato, intendiamoci) e riuscire in una certa misura - scrivere codice Java-idiomatico in JavaScript - ma avranno sempre la sensazione di combattere JavaScript. Manca alcune funzionalità o trova difficile emularle.

Il codice idiomatico è buono. È difficile per l'estraneo, ma possono imparare. Alla fine, il codice deve essere mantenuto per anni, quindi se riesci a trovare una lingua all'interno dei modi di dire il programma sottostante può essere espresso in modo chiaro, è quello che dovresti fare.

Vorrei solo chiarire che esiste sicuramente qualcosa come l'abuso di idiomi (o le caratteristiche del linguaggio sottostante). Se usi modelli C ++ per eseguire parti significative della logica dell'applicazione in fase di compilazione, o se il tuo programma Lisp completo è una chiamata a qualche macro che si svolge in modo praticamente imprevedibile, se la soluzione Java di un semplice problema si gonfia a le proporzioni di FizzBuzzEnterpriseEdition ... stai sbagliando.

La gente dice che il codice deve essere facile da leggere. Questa è solo metà della verità. Deve essere facile da capire, il che richiede che sia anche facile ragionare. Ciò richiede un uso adeguato delle astrazioni. Come per la maggior parte delle cose, si tratta di trovare il giusto equilibrio.