Come spesso si usa pseudocodice nel mondo reale?

Io uso pseudocodice quando si è lontani da un computer e solo avere carta e penna. Non ha molto senso preoccuparsi della sintassi per il codice che non viene compilato (non può compilare la carta).

Per lo più usarlo per Nutting fuori il codice molto complesso, o per spiegare il codice per entrambi gli altri sviluppatori o non sviluppatori che capiscono il sistema.

Ho anche il flusso di diagrammi o diagrammi UML di tipo quando si cerca di fare in precedenza anche ...

Io generalmente lo uso quando si sviluppano più se else nidificati che possono essere fonte di confusione.

In questo modo non ho bisogno di tornare indietro e documentare fin dalla sua già stato fatto.

Abbastanza raramente, anche se spesso mi documentare un metodo prima di scrivere il corpo di esso.

Tuttavia, se sto aiutando un altro sviluppatore con il modo di affrontare un problema, io scrivo spesso una e-mail con una soluzione pseudocodice.

Ho quasi sempre lo uso al giorno d'oggi per la creazione di qualsiasi routine non banali. Creo la pseudo codice come commenti, e continuano ad espandersi fino a quando ho arrivare al punto che posso solo scrivere il codice equivalente di sotto di essa. Ho trovato questo accelera in modo significativo lo sviluppo, riduce la sindrome "basta scrivere codice" che spesso richiede la riscrittura per cose che non sono stati originariamente considerati come ti costringe a pensare attraverso l'intero processo prima di scrivere codice vero e proprio, e serve come buona base per documentazione del codice dopo che è stato scritto.

Io non uso pseudocodice affatto. Sono più a suo agio con la sintassi dei linguaggi di stile C di me con pseudocodice.

Quello che faccio molto spesso per la progettazione è essenzialmente uno stile di decomposizione funzionale di codifica.

public void doBigJob( params )
{
    doTask1( params);
    doTask2( params);
    doTask3( params);
}
private void doTask1( params)
{
    doSubTask1_1(params);
    ...
}

Il che, in un mondo ideale, sarebbe alla fine si trasformano in un codice a lavorare come i metodi diventano sempre più banale. Tuttavia, nella vita reale, c'è un diavolo di un sacco di refactoring e di ripensamento del design.

Troviamo questo funziona abbastanza bene, come raramente veniamo attraverso un algoritmo che è al tempo stesso: incredibilmente complesso e difficile da codificare e non meglio risolto utilizzando UML o altra tecnica di modellazione.

Se sto lavorando fuori qualcosa di complesso, lo uso molto, ma lo uso come commenti. Per esempio, io STUB la procedura, e mettere in ogni passo penso che ho bisogno di fare. Mentre poi scrivere il codice, lascio i commenti: dice quello che stavo cercando di fare.

procedure GetTextFromValidIndex (input int indexValue, output string textValue)
// initialize
// check to see if indexValue is within the acceptable range
//    get min, max from db
//    if indexValuenot between min and max
//       then return with an error
// find corresponding text in db based on indexValue
// return textValue
   return "Not Written";
end procedure;

Non ho mai, nemmeno una volta, bisogno di scrivere lo pseudocodice di un programma prima di scriverlo.

Tuttavia, di tanto in tanto ho dovuto scrivere pseudocodice dopo la scrittura di codice, che di solito accade quando sto cercando di descrivere l'implementazione di alto livello di un programma per avere qualcuno al passo con il nuovo codice in un breve lasso di tempo. E per "l'attuazione di alto livello", voglio dire una sola riga di pseudocodice descrive circa 50 linee di C #, ad esempio:

Core dump un gruppo di file XML in una cartella ed esegue il Process.exe
  eseguibile con alcuni parametri da riga di comando.

Il Process.exe legge ogni file
    Ogni file viene letto riga per riga
    parole uniche sono tirati fuori dal file memorizzato in un database
    File viene eliminato quando la sua trasformazione finale