Quanto spesso usi lo pseudocodice nel mondo reale?

Question

Al college, solo l'uso dello pseudo codice era più evangelizzato dell'OOP nel mio curriculum.Proprio come i commenti (e altre "migliori pratiche" predicate), ho scoperto che in tempi difficili lo pseudocodice veniva spesso trascurato.Quindi la mia domanda è... chi lo usa davvero la maggior parte del tempo?Oppure lo usi solo quando un algoritmo è davvero difficile da concettualizzare interamente nella tua testa?Mi interessano le risposte di tutti:da sviluppatori junior bagnati dietro le orecchie a veterani brizzolati che erano in giro ai tempi delle carte perforate.

Per quanto mi riguarda personalmente, lo uso principalmente solo per le cose difficili.

Answer 1

Io lo uso per tutto il tempo. Ogni volta che devo spiegare una decisione di progettazione, lo userò. Parlando con il personale non tecnico, lo userò. Ha applicazione non solo per la programmazione, ma per spiegare come tutto ciò è fatto.

Lavorare con un team su più piattaforme (Java front-end con un backend COBOL, in questo caso) è molto più facile spiegare come un po 'di codice funziona utilizzando pseudocodice di quanto lo sia per mostrare il codice vero e proprio.

Nel corso fase di progettazione, pseudocodice è particolarmente utile perché aiuta a vedere la soluzione e se sia o non è fattibile. Ho visto alcuni disegni che sembrava molto elegante, solo per provare per la loro attuazione e rendo conto che non riuscivo nemmeno a generare pseudocodice. Si è rivelato, il progettista non aveva mai provato a pensare a un'implementazione teorica. Se avesse tentato di scrivere un po 'pseudocodice che rappresenta la sua soluzione, non avrei mai dovuto sprecare 2 settimane a cercare di capire il motivo per cui non ho potuto farlo funzionare.

Answer 2

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

Answer 3

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.

Answer 4

I e gli altri sviluppatori nella mia squadra lo uso per tutto il tempo. Nelle e-mail, lavagna, o semplicemente in confersation. Psuedocodarlo è tought per aiutarti a pensare il modo in cui è necessario, per essere in grado di programmare. Se psuedocodarlo davvero unstand si può prendere su a quasi qualsiasi linguaggio di programmazione perché la differenza principale tra tutti è la sintassi.

Answer 5

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:. Si 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;

Answer 6

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

Tuttavia, di tanto in tanto ho dovuto scrivere pseudocodice dopo scrittura di codice, che di solito accade quando sto cercando di descrivere l'implementazione di alto livello di un programma per ottenere qualcuno fino a velocità 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 dumps a bunch of XML files to a folder and runs the process.exe
  executable with a few commandline parameters.

The process.exe reads each file
    Each file is read line by line
    Unique words are pulled out of the file stored in a database
    File is deleted when its finished processing

Questo tipo di pseudocodice è abbastanza buono per descrivere circa 1000 linee di codice, e abbastanza buono per informare con precisione un principiante ciò che il programma è in realtà facendo.

In molte occasioni in cui io non so come risolvere un problema, io in realtà trovo disegno miei moduli su una lavagna in termini di altissimo livello per avere un quadro chiaro di come la loro interagenti, disegnando un prototipo di uno schema di database , disegnando un datastructure (soprattutto alberi, grafi, matrici, ecc) per ottenere una buona maniglia su come attraversare e di processo, ecc.

Answer 7

Io lo uso quando spiega i concetti. Aiuta a ritagliare i pezzi inutili di lingua in modo che gli esempi hanno solo i dettagli pertinenti alla domanda che si pone.

Io lo uso una discreta quantità su StackOverflow.

Answer 8

Non faccio uso di pseudo come viene insegnato a scuola, e non avere in un tempo molto lungo.

io uso le descrizioni in inglese di algoritmi quando la logica è abbastanza complessa per giustificarlo; si chiamano "commenti". ; -)

quando spiegare le cose agli altri, o cose lavorando su carta, io uso gli schemi il più possibile - più semplice il migliore

Answer 9

Quello di Steve McConnel Codice completato, nel capitolo 9, "Il processo di programmazione dello pseudocodice" propone un approccio interessante:quando scrivi una funzione più lunga di poche righe, usa un semplice pseudocodice (sotto forma di commenti) per delineare cosa deve fare la funzione/procedura prima di scrivere il codice effettivo che lo fa.I commenti dello pseudocodice possono quindi diventare commenti effettivi nel corpo della funzione.

Tendo a usarlo per qualsiasi funzione che fa più di ciò che può essere rapidamente compreso guardando una schermata (max) di codice.Funziona particolarmente bene se sei già abituato a separare il corpo della funzione in "paragrafi" di codice - unità di codice semanticamente correlato separate da una riga vuota.Quindi i "commenti in pseudocodice" funzionano come "intestazioni" di questi paragrafi.

PS:Alcune persone potrebbero obiettarlo "non dovresti commentare cosa, ma perché, e solo quando non sia banale da capire per un lettore che conosce la lingua in questione meglio di te".In generale sono d'accordo con questo, ma faccio un'eccezione per il PPP.I criteri per la presenza e la forma di un commento non dovrebbero essere scolpiti nella pietra, ma in ultima analisi regolati da applicazione saggia e ponderata del buon senso Comunque.Se ti ritrovi a rifiutarti di provare una leggera inclinazione verso una "regola" soggettiva solo per il gusto di farlo, potresti dover fare un passo indietro e capire se non la stai affrontando in modo abbastanza critico.

Answer 10

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 diagrammi di flusso o di tipo diagrammi UML quando si cerca di fare in precedenza anche ...

Answer 11

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.

Answer 12

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.

Answer 13

Non faccio uso di pseudocodice affatto. Sono più a suo agio con la sintassi dei linguaggi di stile C di me con Pseudocodice.

Quello che faccio fare abbastanza frequentemente ai fini della 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 ci imbattiamo in un algoritmo che è al tempo stesso: incredibilmente complesso e difficile da codificare e non meglio risolto utilizzando UML o altra tecnica di modellazione.

Answer 14

Non ho mai usato o usato.

cerco sempre di prototipo in un linguaggio vero e proprio, quando ho bisogno di fare qualcosa di complesso, di solito scrivendo unit test prima di capire che cosa il codice deve fare.