Studi su come un programmatore può capire il codice in lingue sconosciute? [chiuso]

Esistono studi seri su come un programmatore esperto che conosce la lingua X può comprendere il codice scritto da un programmatore competente che utilizza la lingua Y, per una buona gamma di lingue ampiamente utilizzate come X e Y?

Ovviamente il mondo reale non è così semplice come un programmatore conosce solo una lingua. Quello che vorremmo sapere è: se facciamo il nostro progetto, diciamo, in C #, e un giorno alcuni vecchi fisici che conoscono solo Fortran e Algol lo guardano, fino a che punto avrebbe senso per loro? Parti matematiche potrebbero leggerle bene, se ignorano ciò che per loro sono alcuni segni di punteggiatura casuali. Oppure, un esperto di Python sarebbe in grado di trovare difetti nella mia intelligente sceneggiatura di Ruby?

Potrebbero esserci problemi dal livello della sintassi superficiale al livello dei grandi concetti come oggetti, metaprogrammazione di modelli, funzionali e così via. Non mi aspetto che un solo programmatore comprenda appieno tutti i dettagli della sintassi del codice in una "lingua straniera" o segua la religione di qualche grande concetto, ma mi chiedo fino a che punto otterrebbero il flusso principale di controllo, trovare lo spot dove qualcosa viene disegnato sullo schermo e cosa ne determina il colore o le dimensioni, verifica che un robot programmato per guidare un'auto spenga il motore quando ha finito, quel genere di cose.

Uno studio di buona qualità includerebbe ricerche accademiche pubblicate, un rapporto ufficiale di alcuni gruppi industriali o importanti società di software, anche se prenderò sistematiche osservazioni imparziali da parte di esperti leader di seminari e lezioni o altre fonti. Non interessato a brevi blog, esempi a caso singolo o aneddoti. (Beh, forse alcuni aneddoti se rendono una buona lettura.)

Dipende ovviamente dal grado di relazione tra le lingue. Ad esempio, se si dispone di uno sfondo C o C ++ e si è eseguita una programmazione C # o Java, dovrebbe essere facile leggere e comprendere l'altro dei due linguaggi (Java o C #). Se conosci bene Lisp, Scheme non dovrebbe essere un grosso problema. Una volta ho eseguito il debug di un programma PHP senza avere alcuna conoscenza di PHP, solo con le mie conoscenze di C, C ++ e Perl. Sono abbastanza sicuro quando quel programma sarebbe stato scritto in Haskell o Smalltalk, sarebbe stato immensamente più difficile quasi impossibile per me.

In effetti, non credo che una ricerca accademica su questo argomento avrebbe alcun senso (almeno, non seria). Non esiste un "programmatore con esperienza standard che conosca il linguaggio X", quindi qualsiasi studio mancherebbe i dati di base garantiti. Le persone hanno conoscenze diverse e, anche se hanno frequentato le stesse scuole, hanno un talento e una motivazione diversi.

ma chiedendomi fino a che punto otterrebbero il flusso principale di controllo, trova il punto in cui qualcosa è disegnato sullo schermo

Questo può essere difficile anche quando hai molta familiarità con la lingua, o perché la qualità del codice è così bassa, o il framework utilizzato è così complesso, o la base di codice è molto grande.

Non sono sicuro di un riferimento allo studio condotto accademicamente, tuttavia una denominazione autoesplicativa di metodi, classi e funzioni nei linguaggi C # / C ++ / Java / Python o ecc. Dovrebbe consentire di comprendere facilmente la base di codici e il flusso dei processi aziendali.

La convenzione di denominazione all'interno del progetto e generalmente nello sviluppo del software è un aspetto molto importante. Tuttavia, laits importancerilevanza per la creazione di software di qualità è spesso trascurata o ignorata tutti insieme.

Anche le Linee guida per i nomi utilizzate in .NET Framework e le Convenzioni generali sui nomi utilizzate in .NET sono buoni riferimenti.

Dipende enormemente dal singolo programmatore e da come interiorizzano le lingue. Non ho assolutamente problemi a lavorare in una dozzina di lingue, mentre ho un amico che conosce solo C ++. In programmazione non è peggio di me, ha appena imparato un modo diverso.

Personalmente, trovo più interessante una domanda correlata: quando c'è un bug nel codice (cioè il programmatore X pensava di aver scritto someFunction(x, y)ma in realtà ha scritto qualcos'altro), quanto è difficile per il secondo sviluppatore identificare il bug. Un buon programmatore X renderebbe estremamente ovvio cosa DESIDERI fare il computer, e sarebbe facile da leggere. Tuttavia, se ha commesso un errore, può essere un grosso problema. Cose come il seguente bug C ++:

int x = getCorrectValueForX();
if (x = 2)
   doSomethingWhenXIsTwo();

Può essere notoriamente difficile da rilevare se non si conosce la lingua.

Non dipende solo dal programmatore come hanno detto altre persone, ma anche dalle somiglianze tra le lingue, sia nella sintassi, sia nella filosofia e nell'implementazione.

Molte lingue diverse usano una sintassi derivata C, quindi seguire il flusso di controllo sarà più facile se hai familiarità con quel tipo di sintassi. Lo stesso vale per linguaggi fortemente tipizzati e vagamente tipizzati, linguaggi con supporto di funzioni di ordine superiore, livello di astrazione e filosofie programmatiche. Dipende non solo dalla capacità di leggere la sintassi, ma anche dalla conoscenza dei concetti linguistici e delle filosofie.

Se hai imparato C per esempio, penso che sarebbe ragionevole aspettarti che tu possa derivare il flusso di controllo da C #, Java o C ++ ecc. Sarebbe un po 'più difficile decifrare VB a causa della differenza nella sintassi, oppure JavaScript a causa di chiusure, digitazione debole e funzioni di ordine superiore (so che puoi farlo in C ma è un po 'traballante). Non mi aspetterei, tuttavia, che tu sia in grado di eseguire il debug di Lisp, F #, R o, Dio non voglia, assembly perché utilizzano un paradigma di programmazione completamente diverso.

TL; DR Non è solo importante essere in grado di riconoscere la sintassi, il più delle volte è possibile decifrare una dichiarazione o una chiamata di metodo, ma essere in grado di comprendere il motivo per cui un programma è scritto in un certo modo è il nocciolo della comprensione e della lettura del codice .