Ci sono casi in cui è preferibile il codice reale e casi in cui è preferibile lo pseudocodice. Non dovresti fare affidamento su una semplice regola di ferro, ma piuttosto sul giudizio di ciò che è appropriato alla situazione.

Alcune cose da considerare:

I linguaggi di programmazione vanno e vengono . Negli anni '60, Fortran era considerato un linguaggio di programmazione davvero piacevole e leggibile, molto più facile da leggere rispetto a Assembly. Ma se avessi scritto un articolo utilizzando esempi di codice Fortran invece di peudocode, sarebbe più difficile da leggere per noi ora. In questo momento, Python ci sembra piuttosto buono, ma sarà ancora così bello in futuro? Se ti ho consegnato un pezzo di codice Python con il seguente codice:

  a = 3/2  

Qual è il valore di a ? È 1 o 1,5? Perché Python 2 e 3 gestiscono la divisione intera in modo diverso. Ora, sono passato alla programmazione più o meno nativa in Python 3, quindi ho dovuto cercare quali delle operazioni di divisione in Python 2 e 3 sono diverse e quali no. Solo per mostrarti, l'utilizzo di codice reale in un documento può ridurre la durata di conservazione del tuo foglio.

Lo pseudocodice ti consente di astrarre le cose Nello pseudocodice puoi semplicemente affermare qualcosa come:

  WHILE criterio di arresto non raggiunto DO (cose)  

E poi più avanti nel tuo articolo puoi discutere su diversi possibili criteri di arresto per il tuo algoritmo. Potresti farlo anche con il codice Python effettivo, ma il risultato sarebbe fondamentalmente che stai torcendo il tuo codice Python per fare ciò che lo pseudocodice fa per natura.

Puoi essere abbastanza standardizzato in pseudocodice Usa semplicemente le varie opzioni di composizione dell'algoritmo per LaTeX.

Puoi usare la notazione matematica in pseudocodice Usare la notazione di insiemi matematici è molto più universale che fare affidamento su tutti i tuoi lettori comprensione delle operazioni sugli insiemi di Python. Considera:

  a = set ([1, 2, 3]) b = set ([1, 2]) c = 1 if b.issubset (a) else 0  

contro

  A ← {1, 2, 3} B ← {1, 2} C = 1 if B ⊆ A 0 altrimenti  

Qualcuno non ha familiarità con Python guardando il il primo esempio si chiederà: è [1, 2, 3] a ... forse un elenco? Bene, la lista [1, 2, 3] non è la stessa della lista [1, 2], quindi l'insieme A e l'insieme B contengono elementi diversi, quindi B non può essere un sottoinsieme di A.

Algoritmi e implementazioni Supponi di scrivere nel 2019 un algoritmo interessante in Python 3 utilizzando alcune librerie all'avanguardia. Nel 2025 ho escogitato un algoritmo alternativo per lo stesso problema in Go e voglio confrontare le prestazioni per dimostrare che il tuo è migliore. Per ottenere un confronto equo, dovrò implementare il mio algoritmo in Go o il tuo in Python. Supponiamo che a quel punto nessuno usi più Python per cose ad alte prestazioni perché Go lo fa meglio. (Potrebbe, non so.) Ora devo andare a cercare le librerie di sette anni che hai usato per scoprire esattamente quali funzioni hai usato e quali funzioni Go sono equivalenti a loro. È molto difficile. Quindi molto probabilmente, l'implementazione Go che faccio del tuo algoritmo non sarà poi così buona. E grande sorpresa! Il mio algoritmo si confronta meglio del tuo!

Ora, invece, se avessi utilizzato una descrizione del tuo algoritmo indipendente dall'implementazione, le cose potrebbero andare meglio per la tua pubblicazione.

Quindi i due grandi svantaggi dell'utilizzo del codice reale sono: limita la durata di conservazione della tua pubblicazione e raggiungi un pubblico più ristretto.

Quindi, quando dovresti utilizzare il codice reale?

• Quando l'argomento del tuo articolo non è l'algoritmo, ma l'implementazione o il linguaggio di programmazione. Forse stai cercando di dimostrare che Python è davvero un buon linguaggio in cui risolvere il problema X perché con le librerie Y e Z ottieni un'implementazione facile ed efficiente.

• È assolutamente incoraggiato anche pubblicare il tuo codice reale come appendice o, meglio ancora, in un repository dove le persone possono scaricare il tuo codice e suggerire miglioramenti. Un algoritmo non banale è probabilmente troppo grande per essere copiato digitandolo a mano o comunque copiando e incollando da un foglio. Non appena inizi a entrare in qualcosa come un nuovo algoritmo di Deep Learning, probabilmente stai guardando più file o persino pacchetti nidificati.

Nella mia ricerca, scrivo spesso algoritmi, che possono contenere affermazioni come:

• Trova un sottospazio dominante di una data matrice ermitiana A con relativa precisione Ɛ .
• Trova una soluzione non negativa di questo sistema di equazioni / disequazioni.
• Ordina questi autovalori da grandi a piccoli in modulo, scartare quelli piccoli e rimescolare gli autovettori di conseguenza.

Queste istruzioni sono perfettamente semplici e chiare per chiunque faccia Algebra Lineare Numerica, indipendentemente dal proprio linguaggio di programmazione preferito. Non vedo alcun motivo per utilizzare un particolare linguaggio di programmazione nel documento e rischio di limitare i miei lettori. Credo che il linguaggio naturale sia più veloce da leggere e capire. In particolare, mi permette di parlare chiaramente di qual è lo scopo di ogni passaggio, piuttosto che di come raggiungerlo. Ci sono spesso più modi per, ad es. "risolvere un sistema lineare", e l'uso di pseudo-codice mi permette di distinguere tra "risolverlo in qualche modo" e "risolverlo usando questo particolare algoritmo". Quindi, utilizzo uno pseudo-codice che mi consente di esprimere meglio sfumature come questa.

Fornisco sempre codice effettivo insieme al foglio in un repository aperto, che i lettori possono clonare ed esplorare, risparmiando loro il fastidio di riscrivere il codice dalla versione pdf / stampata del documento.

Lo pseudo-codice è per sempre; i linguaggi reali cambiano continuamente.

Se avessi pubblicato un articolo con un algoritmo in Python nei 2 giorni di Python, c'è una significativa possibilità che il codice "eseguibile" che hai scritto allora non funzionerà più correttamente se le persone lo eseguono con l'ultima versione, anche in casi meno drammatici l'avanzamento di nuove librerie e algoritmi rischia di lasciare i lettori confusi riguardo alle tue scelte arcaiche. Immagina se giornali di 40 anni fa avessero usato le lingue del giorno; capiresti le sottigliezze di alcuni codici Fortran o Pascal? I programmatori hanno quindi fatto le stesse affermazioni per la comprensibilità che fai su Python.

Quindi lo pseudo-codice è migliore perché esprimerà chiaramente le idee chiave altrettanto bene tra cento anni.

Lo pseudo-codice esprime l'intento del codice meglio dei linguaggi reali

Per scrivere codice funzionante devo, quasi sempre, eseguire una serie di passaggi per far funzionare il programma che non sono necessari per impostare le cose, formattare le cose o altro, questi passaggi possono essere ignorati o semplificati in pseudo-codice per comunicare le informazioni importanti.

Inoltre, nelle lingue reali devo prendere decisioni su come vengono archiviati i dati, quale algoritmo viene adottato per l'ordinamento, ecc. che sono secondari all'algoritmo discusso nel documento. Includendo queste scelte accidentali nella descrizione dell'algoritmo si guidano gli implementatori a fare scelte che potrebbero non essere ottimali, o perché ora sono disponibili scelte migliori o perché le scelte che hai fatto non sono adatte al loro ambiente di destinazione.

Gli argomenti che hai sentito sono tutti probabilmente corretti. Sono stato un revisore e autore di molti articoli di informatica, vorrei rispondere a questa domanda a modo mio e come mi sento.

Lo pseudo codice è più breve. Dato un linguaggio moderno come Clojure o Python, il codice reale spesso non è molto più lungo. Anche se lo è, la carta (elettronica) costa poco.

Lo pseudo-codice è breve e chiaramente comprensibile. Lo pseudo-codice aiuta a decodificare l'idea in modo molto chiaro rispetto a un intero codice. Non trascorrerò alcune ore del mio tempo a capire il tuo codice. Ad esempio, per ordinare un file CSV in base alla terza colonna, potresti aver scritto 3 righe, cosa che non mi interessa davvero. Devo solo capire che il file deve essere ordinato. Secondo, cosa succede se non mi piace la lingua in cui è scritto il codice. Potrebbe esserci un enorme pregiudizio in tale revisione e interesse.

Non tutti possono programmare in Python. Vero, ma il codice Python ben scritto non è più difficile da leggere dello pseudocodice. Inoltre, Python è standardizzato - lo pseudo codice personale di qualcuno non lo è.

Questa è solo un'affermazione che la comunità Python è per tutti. Questo vale anche per molti altri linguaggi: script Matlab, script R, script Java; alcune persone (ad esempio io) amano anche gli script di shell UNIX.

In CS, ci concentriamo sugli algoritmi, non sulle implementazioni. Vero, ma anche mostrare le implementazioni non toglie questo focus.

Sono d'accordo. Ma guardare l'intero codice non ha senso. Leggi il primo punto.

Preferisce una lingua rispetto a un'altra. Vero, ma questo è un diritto che ho come autore, non è vero?

Dovresti capire che stai scrivendo la carta per "il mondo tranne te stesso". Quindi, non sei da nessuna parte nel gruppo dei lettori previsti. Dovresti scrivere qualcosa che i lettori leggeranno per non infastidirsi.

Sembra amatoriale. Questo è soggettivo.

In effetti.

Verdetto: puoi sempre fornire il codice completo nel tuo articolo (come in Appendice o in Materiale supplementare). Tuttavia, devi fornire un algoritmo / pseudocodice nel documento principale.

Mi piacciono le attuali tre risposte principali in questo momento (di @ObscureOwl, @DmitrySavostyanov e @JackAidley). Ma mi sembra che ci sia un'opzione che non viene rappresentata.

Puoi fornire sia lo pseudo-codice che il codice reale.

• Molto probabilmente il codice reale il codice è troppo lungo per essere fornito in linea nel tuo articolo.
• Quindi dovresti fornire lo pseudo-codice nel documento.
• Quindi il codice reale come addendum o supplemento -download o URL.

Fornire entrambi ti dà tutti i vantaggi di entrambi AND altro.

• Hai tutti i vantaggi dello pseudo-codice.
• Hai tutti i vantaggi del codice reale.
• Così i tuoi lettori possono capire più facilmente il tuo articolo leggendo lo pseudo codice e comprendendo l'intento e poi, se sono molto seri, possono vai al codice reale e inizia a usarlo.
• Il codice è più facile da capire perché hanno già lo pseudocodice che spiega l'implementazione di basso livello.

Infine fornendo entrambi garantiscono una comprensione a lungo termine (lo pseudo-codice non diventa obsoleto) E la tua ricerca a breve / medio termine ottiene più adozione, più utilizzo, più facile riprodurre i risultati.

• Più adozione / utilizzo / riproduzione a breve termine significa maggiore impatto a lungo termine sugli altri e più utilizzo a lungo termine.

Esempio n. 1

https://academia.stackexchange.com/a/140990/349 è un ottimo esempio in cui lo pseudo-codice è molto più leggibile / comprensibile / l'intento è ovvio ... l'implementazione di questo nel codice richiederebbe molte righe di codice e potrebbe diventare brutto rapidamente e occupare troppo spazio in un documento ... quindi vorresti sicuramente lo pseudo- codice ... ma se fossi serio e volessi usare la carta ... avere il codice reale mi farebbe risparmiare molte ore ... in alcuni casi molte ore / settimane / giorni / mesi di ricreare lo pseudo-codice.

Esempio n. 2

Ecco un altro esempio. http://www.fftw.org/fftw-paper-ieee.pdf L'algoritmo FFTW serve per calcolare la trasformata di Fourier. L'articolo parla di algoritmi ma anche l'implementazione è molto importante. Quindi il documento fornisce principalmente pseudo-codice e un po 'di codice. E se vuoi il sorgente, puoi ottenerlo come download supplementare.

Nella mia esperienza sia come autore che come lettore, è altamente preferibile utilizzare codice reale piuttosto che pseudocodice quando possibile. mai un revisore si è lamentato quando ho utilizzato codice reale anziché pseudocodice.

Inoltre, il codice reale è vantaggioso non solo perché il lettore può eseguirlo da solo, ma anche perché autore può eseguirlo e assicurarsi di non avere bug nella presentazione.

Tuttavia, rendere un vero codice eseguibile buono per la presentazione come algoritmo è spesso ancora abbastanza difficile:

• Il codice eseguibile correttamente non è necessariamente comprensibile. Deve essere accuratamente pulito, commentato e organizzato.
• Se l'articolo include analisi, le variabili del codice devono corrispondere alle variabili dell'analisi, il che può essere problematico con notazioni matematiche più complesse ("x_hat_sub_i_prime")
• Le lunghezze delle righe spesso devono essere molto più brevi per adattarsi a una colonna di carta, il che aggiunge ulteriore riformattazione e spesso bruttezza.
• Ci sono spesso parti "non interessanti" ma necessarie del codice, come il riempimento e decomprimere le informazioni dalle strutture di dati.
• Il codice spesso rimane impigliato con dipendenze, ambiente e contesto.
• Alcune lingue sembrano essere intrinsecamente "prolisse" e difficili da creare elenchi compatti con .

Alla luce di tutto ciò, penso che molti autori potrebbero trovare più semplice mettere insieme qualche pseudocodice incerto piuttosto che cercare di ottenere un codice reale per essere sia presentabile che corretto.

Lo pseudo codice ti consente di concentrarti sui bit importanti dell'algoritmo e di riassumere il resto.

Il codice reale spesso inizia con il caricamento di alcune librerie, la lettura di alcuni dati, quindi la formattazione / riorganizzazione nel modo desiderato, non necessario nello pseudo codice.

Il tuo algoritmo potrebbe consistere in più passaggi separati, alcuni dei quali sono standard, ben compresi e noiosi, altri sono l'innovazione chiave nel tuo articolo. Nello pseudo codice, i bit noiosi sono solo battute che descrivono ciò che deve accadere. I pezzi succosi sono dettagliati quanto devono essere. Nel codice reale alcuni dettagli standard saranno più lunghi dei pezzi effettivamente importanti.

Quindi, in sintesi, nello pseudo codice il lettore può facilmente vedere dove sono i bit importanti nel tuo codice, con il codice reale questo è molto più difficile (non impossibile, solo più difficile).

Direi che questa è più una convenzione, poiché sembra molto dipendente dal campo. Nei documenti "combinatori" di algoritmi discreti, non vedo quasi mai codice reale. Bene, un'eccezione degna di nota è il TAoCP di Don Knuth, ma non tutti sono Don Knuth, giusto?

Tuttavia, in un campo in cui lavoro (programmazione funzionale), presentare codice reale ed eseguibile è la norma . Gran parte della ricerca dipende davvero dal linguaggio, quindi non sorprende, ma anche il lavoro indipendente dal linguaggio (ad esempio, strutture di dati puramente funzionali) viene tipicamente presentato utilizzando un vero linguaggio di programmazione funzionale come Standard ML o Haskell. A volte questo crea un po 'di confusione, ma poiché la programmazione funzionale come campo (anche se probabilmente fa ancora parte per lo più di TCS) è piuttosto orientata all'implementazione e alla programmazione, la maggior parte delle persone vuole vedere programmi reali. p>

Quindi IMO questa è davvero più una convenzione che altro, e dipende davvero dal campo. La maggior parte dei combinatori si preoccupa dell'algoritmo stesso ad alto livello così come della sua complessità, ma i programmatori funzionali (o forse i "logici") si preoccupano molto del fatto che l'algoritmo possa essere implementato correttamente ed elegantemente, da qui la discrepanza.

Non deve esserci una chiara distinzione.

La parte più importante dello pseudo codice è che dovrebbe essere chiaro da leggere. Quindi non vuoi avere a che fare con costrutti che non fanno parte dell'algoritmo vero e proprio e non vuoi avere a che fare con costrutti di sintassi, che sono utili in un linguaggio di programmazione, ma di non facile comprensione quando non conosci il linguaggio di programmazione.

È questo pseudo codice o codice reale?

  if a == b: a = a% b  

Questo è valido codice Python. Ma è anche uno pseudo codice leggibile.

Che ne dici di questo?

  for i in range (10): print (i)  

Direi che questo non è uno pseudo codice (buono), poiché il costrutto for non è ovvio.

Potresti essere in grado di ottenere il for i nella parte , ma cosa fa range (10) ? Anche range (0, 10) non è molto chiaro, perché non è ovvio che 10 non fa parte dell'intervallo.
Inoltre, è necessario mantenere in mente, che la matematica e l'informatica spesso differiscono nell'iniziare gli indici con 0 o 1.

quindi direi che questo è molto più chiaro, ma nessun codice valido:

  for i = 0 .. 9: print (i)  

Ci sono altri modi per esprimere l'intento del ciclo for, che sono simili, chiari e facili da leggere. Qui potresti provare a usare la sintassi C per (int i = 0; i < 10; i ++) , o forse anche omettere int .

Ciò che appartiene a un buon pseudo codice è un chiaro elenco leggibile dall'uomo dell'input e dell'output. Quindi non

  int i = 0; i: = i + 1return i;  

ma piuttosto utilizzare

  // input: // i: un numero intero che dovrebbe essere incrementato // Algoritmo: o: = i + 1 // output: // o: il numero intero incrementato di 1  

Nota che ho evitato di riutilizzare i per memorizzare il risultato, ma ho utilizzato una variabile o che viene utilizzata solo per memorizzare l'output. Ciò consente di omettere anche l'istruzione return , quindi il lettore non ha bisogno di pensare a cosa fa return e dove ritorna non è rilevante per l'algoritmo.

In Contrariamente all'esempio all'inizio, ho usato : = per l'assegnazione, per rendere più ovvio che si tratta di un'operazione di assegnazione e nessuna equazione matematica.

Ovviamente il tuo stile personale contiene molte delle tue opinioni sullo pseudo codice pulito. Se non sei sicuro, potresti voler rimanere vicino ai diversi pacchetti di pseudo codice in LaTeX e usarli in modo simile agli esempi nella loro documentazione.

C'è stato un tempo in cui lo pseudocodice era la scelta più chiara, poiché i linguaggi di programmazione erano così rudimentali. Anni '60 e '70, ma più tardi, ci vuole tempo per presumere con sicurezza che una lingua sia di uso generale e, al momento, non usare lo pseudocodice sembrava strano. Ricordo lo pseudocodice che includeva costrutti a torta nel cielo come: "foreach", for-loops, loop at all (al contrario di un IF con un GOTO all'indietro), array 2D, if's with else, funzioni con parametri, variabile nomi più lunghi di 2 lettere, una libreria di stringhe funzionante. In sostanza, lo pseudocodice era un linguaggio migliore e superiore.

Alcuni accademici non codificano molto e probabilmente hanno gli stessi ricordi che ho io, dove "trasformare questo pseudocodice in un programma FORTRAN" non era -assegnazione banale. Da parte mia, ricordo di aver scritto lo pseudocodice intorno al 2010 (vecchie abitudini), realizzando che funzionava al 99% in C ++ e che lo pseudocodice non è più una cosa. Stai solo pensando e scrivendo nel tuo linguaggio di programmazione preferito, con alcune scorciatoie qua e là.

La pubblicazione di codice eseguibile invece di pseudo codice viene evitata?

Non che io sappia, ma questo probabilmente dipende dalla sottocultura specifica del rispettivo campo.

In Informatica è preferibile descrivere algoritmi usando pseudo codice piuttosto che codice reale?

Lo era (vedi la risposta di Owen) e talvolta può ancora essere (vedere le considerazioni di seguito).

Se sì, perché?

[...]

Quindi quali sono gli argomenti codice?

Come molte altre risposte già affermano: A parte il codice ingenuo eseguibile, lo pseudo codice mira ad essere facilmente letto e compreso senza disturbare il lettore con cose non importanti (per l'aspetto presentato) dettagli. E di solito riesce a raggiungere questi obiettivi.

Come tu stesso affermi, anche il codice eseguibile ha i suoi vantaggi. Consentitemi quindi di eludere la questione affermando che

con un po 'di sforzo potete ottenere il vantaggio di entrambi

(e senza fornire entrambi, pseudo codice e separati codice eseguibile, come suggerisce syn1kk.)

Il codice ideale nei documenti (e, se fattibile, altrove) è pseudo -pseudo codice: Codice che ha tutte le proprietà positive dello pseudo codice, ma sembra essere eseguibile (e in realtà fa quello che sembrava).

È mia ferma convinzione che tutto eseguibile sufficientemente ben scritto il codice è indistinguibile dallo pseudo codice : se qualcuno può dire che un determinato codice (effettivamente eseguibile) non è uno pseudo codice perché non è così leggibile e facilmente comprensibile come lo pseudo codice, quel codice eseguibile non è strutturato bene abbastanza, ancora, e dovrebbe essere riformattato.

Come ottenere uno pseudo pseudo codice

Come si ottiene un codice eseguibile facile da leggere come uno pseudo codice?

Ci sono diversi aspetti da considerare e realizzarli tutti potrebbe non essere sempre facile o fattibile, o talvolta nemmeno possibile. (Questo può essere un motivo valido per utilizzare un vero e proprio pseudo codice non eseguibile invece di uno pseudo-pseudo codice eseguibile.)

Scegli la lingua giusta

La lingua più adatta dipende da molti cose:

• Il dominio del problema
• Il tuo approccio alla soluzione
• Il tuo pubblico
• Le possibilità che la lingua offre per (ri) strutturare il codice

Nota che per alcune combinazioni di questi, nessun linguaggio di programmazione può (ancora o talvolta anche mai) esistere che consenta di scrivere codice sufficientemente ben scritto. Per ovvie ragioni pratiche, dovrai anche tenere in considerazione la tua padronanza della rispettiva lingua (quanto sei abile nell'applicarla).

Rendi il tuo codice estremamente pulito: refactoring, refactoring, refactoring

Se ci sono dettagli di implementazione che offuscano l'idea centrale dell'algoritmo che stai descrivendo, estraili (ad es. in costanti, variabili, metodi o funzioni), in modo da poter sostituire il loro "come" (la loro implementazione) con il loro "cosa" (il nome della cosa in codice appena estratta). Se appropriato, scegliere di non mostrare l'implementazione o l'assegnazione estratti negli estratti del codice in-paper. Prestare estrema attenzione nel nominare le cose estratte, in modo che il loro scopo (non necessariamente la loro implementazione) sia estremamente chiaro e ovvio dal loro nome e dalla firma della chiamata.

D'altra parte, se un algoritmo è troppo disperso tra diverse parti del codice per essere prontamente comprese, potrebbe essere necessario inserire selettivamente codice inline.

In tutto ciò, mira a un singolo livello di astrazione per unità di codice (ad es. funzione) o, almeno, ai giusti livelli di astrazione per mostrare e spiegare al meglio l'algoritmo. Sebbene applichi il principio della singola responsabilità in qualche modo correlato solo con attenzione: applicarlo eccessivamente (o interpretare "responsabilità singola" troppo ristretto) può disperdere e quindi offuscare il tuo algoritmo. Si noti che a questo proposito, il giusto equilibrio per il codice da presentare in un articolo molto probabilmente sarà diverso dal giusto equilibrio per il codice in un prodotto software (da mantenere).

Con qualsiasi ottimizzazione sufficiente compilatore o interprete, nessuno di questi refactoring dovrebbe influire negativamente sulle prestazioni. Ma quando l'obiettivo è presentare un algoritmo piuttosto che implementarlo in un sistema di produzione, questo non dovrebbe essere di troppo preoccupante, comunque.

Rendi il tuo codice ovvio da interpretare

La corretta interpretazione del tuo pseudo pseudo codice non dovrebbe fare affidamento sulla conoscenza del linguaggio di programmazione scelto, o della sua versione, variante o dialetto. Quindi fai attenzione alle caratteristiche del linguaggio che usi.

Ogni caratteristica del linguaggio che è comune a molti linguaggi di programmazione (nota al pubblico) e che nella lingua scelta ha una sintassi simile a molti altri linguaggi di programmazione potrebbe semplicemente oltre a essere anche una caratteristica di un dialetto pseudo codice e può quindi essere utilizzato in pseudo pseudo codice, a meno che il linguaggio di programmazione scelto non abbia una semantica insolita e non ovvia. Anche una caratteristica non così comune o specifica del linguaggio, o una con una sintassi non così comune, può essere utilizzata senza problemi, se la sua semantica è sufficientemente evidente dalla sua sintassi e parole chiave e dalla loro relazione con il linguaggio naturale.

È meglio omettere le caratteristiche linguistiche non ovvie, ma possono essere utilizzate se combinate con spiegazioni nei commenti in codice o nella prosa dell'articolo. (Proprio come si applicherebbe a caratteristiche non ovvie di uno pseudo dialetto codificato.)

Lo stesso vale per gli idiomi specifici della lingua: evitali o spiegali, se devi aspettarti che non siano evidenti per il tuo pubblico.

Alternativa: rendi eseguibile lo pseudo-codice

Le due sezioni precedenti presuppongono che si inizi dal funzionamento del codice eseguibile. Ovviamente puoi anche iniziare da pseudo codice e modificarlo per renderlo effettivamente eseguibile (e, si spera, per fare quello che sembra) in un linguaggio di programmazione adatto. Nota, tuttavia, che in questo modo potresti ritrovarti con un codice molto non idiomatico per la lingua di destinazione, che potrebbe non essere quello che desideri. Ovviamente, il refactoring di solito può risolverlo.

Spiega il tuo codice

Proprio come dovresti spiegare (in prosa, commenti sul codice o callout) alcuni aspetti del tuo codice se fosse presentato in pseudo codice, devi farlo se è scritto in pseudo pseudo codice.

I vantaggi dello pseudo pseudo codice

• Leggibile e comprensibile come pseudo codice
• Se viene specificata la lingua utilizzata (inclusa versione, variante o dialetto, se applicabile):
  • è eseguibile e utilizzabile
  • è testabile sia manualmente che in automatico test
  • è profilabile

Alcuni di questi vantaggi ti avvantaggiano come autore, come puoi per esempio assicurarti che (r) l'algoritmo presentato è effettivamente corretto. Altri avvantaggiano il tuo pubblico che potrebbe voler valutare il tuo algoritmo

Se questi benefici valgono il lavoro significativo richiesto per ottenere uno pseudo pseudo codice rispetto al solo pseudo codice o d'altra parte non sufficientemente ben scritto eseguibile sta a te decidere.

Oh, e non dimentichiamo il vantaggio morale: che "sembri amatoriale" o no, puoi essere certo che non lo è, grazie a tutta l'abilità e il duro lavoro che richiede.

Per un certo periodo alla fine degli anni Sessanta, CACM richiedeva che gli algoritmi negli articoli fossero scritti in Algol. Hanno abbandonato il requisito quando si è scoperto che le persone inviavano algoritmi sviluppati in altri linguaggi e non testati in Algol (perché non avevano un compilatore Algol installato nei loro siti). Una conseguenza di questo comportamento era che quasi nessuno dei gli algoritmi pubblicati erano compilabili e molti contenevano errori sostanziali causati dall'incomprensione degli autori della semantica Algol.

Penso che gli editori CACM fossero consapevoli della situazione del compilatore quando stabilirono il requisito, ma speravano che l'esistenza di un chiaro standard risulterebbe in uno pseudo-codice non ambiguo.

In ogni caso, questo esempio mostra: * Anche con un grande documento standard che lo descrive, lo pseudo-codice è difficile da scrivere * Il controllo di qualità è più facile con il codice eseguibile.

Dico questo senza voler mancare di rispetto a nessuno, ma molti accademici non sono appassionati programmatori: non piace programmare né si preoccupano dei dettagli. La programmazione non è ciò per cui si sono iscritti o non è l'obiettivo principale del loro lavoro. Possono vedere il codice come un "male necessario", piuttosto che come il contributo o l'apprezzamento del suo design. Il codice è percepito come poco importante e di basso livello. Tutto ciò è soggettivo, ovviamente: posso essere in estrema minoranza, ma personalmente trovo il codice Java più facile da capire rispetto ai diagrammi UML.

A mio avviso, l'intera discussione riguarda la sintassi. C'è un motivo per cui puoi copiare-incollare il codice Python e nessuno batterà ciglio (suggerimento: è ampiamente conosciuto anche dai dilettanti), mentre non puoi con lingue che hanno una curva di apprendimento più ripida e più sfumature. Accade così che quando le persone vedono un codice che non gli piace (o, più probabilmente, non riescono a capire, forse in parte a causa della scarsa familiarità con la sintassi), potrebbero perdere gran parte del contributo.

Lo pseudo-codice è intrinsecamente progettato per algoritmi procedurali che richiedono semplici costrutti IMO. A volte può essere molto più espressivo scrivere codice eseguibile a seconda di ciò che stai dimostrando. Inoltre, significa che non dovrai inventare la tua sintassi, dal momento che la maggior parte degli "standard" di pseudocodice hanno solo costrutti imperativi di base.