Quando dovrei usare lo pseudocodice anziché il diagramma di flusso?

Sono uno studente che lavora con varie tecniche di programmazione e ho incontrato pseudocodici e diagramma di flusso. So che entrambi sono usati per riflettere sul problema prima di programmare, ma ho alcune domande a riguardo.

1. Quando dovrei usare lo pseudocodice per pianificare e quando dovrei usare i diagrammi di flusso? O è meglio fare entrambe le cose prima di programmare davvero. Soprattutto per un piccolo tipo di gioco arcade in JAVA poiché questo è il mio prossimo progetto.
2. Ho notato che lo pseudocodice è molto simile al codice attuale piuttosto che ai diagrammi di flusso. Ciò renderebbe lo pseudocodifica migliore perché essenzialmente copi / incolli lo pseudocodice nel tuo programma (ovviamente, devi cambiarlo per adattarlo alla lingua. Capisco quella parte).
3. È pratico utilizzare entrambi durante la programmazione? In particolare lo stesso gioco menzionato in precedenza. Grazie.

Diagrammi di flusso e pseudocodice hanno spesso lo stesso livello di espressività, ma differiscono nella linearizzazione. Lo pseudocodice è lineare (cioè una sequenza di linee con istruzioni), un diagramma di flusso no. Pertanto, i diagrammi di flusso hanno un livello di astrazione più elevato, utilizzato prima di scrivere pseudocodice o per la documentazione.

I diagrammi di flusso hanno, secondo me, due forti vantaggi rispetto allo pseudocodice: in primo luogo, sono grafici. Molte persone non tecniche hanno una forte paura del testo strutturato, ma non delle descrizioni grafiche, quindi i diagrammi di flusso si adatteranno molto meglio a loro. In secondo luogo, i diagrammi di flusso sono molto meglio nell'esprimere meta-considerazioni come mostrare la linea principale di esecuzione rispetto ai rami.

Le tue domande in dettaglio:

1. Per un problema davvero complicato, dovresti prima utilizzare i diagrammi di flusso, quindi lo pseudocodice. Entrambi sono opzionali quando ti senti abbastanza sicuro.
2. Sì, lo pseudocodice ha il vantaggio di essere unificabile con il codice reale. Steve McConnell, ad esempio, raccomanda vivamente di scrivere prima i metodi nello pseudocodice e poi di lasciare lo pseudocodice nel codice come commenti.
3. Ho sempre sentito che la necessità di disegnare un diagramma di flusso durante la progettazione mostra una partizione insufficiente del problema. Diagrammi di flusso non banali indicano una logica contorta, che dovrebbe essere evitata a costi elevati.

Sul codice pseudo

Ad essere sincero, non uso molto lo pseudocodice. In genere è più veloce scrivere semplicemente il codice, quindi quando ho finito con il mio codice, è il codice effettivo. Ci sono alcuni casi in cui lo pseudo codice può essere utile, ma in genere stai lavorando a qualcosa di molto complesso e stai solo cercando di scomporre la struttura di un metodo o qualcosa. In questi casi, utilizzo i commenti nel mio IDE per strutturare la struttura fino a quando non riesco a ottenere le cose giuste. Quindi, entro e scrivo il codice effettivo nei commenti. Questo mi aiuta a fare alcune cose:

• Posso vedere le aree che ho e non ho implementato leggendo i commenti e vedendo ovvi vuoti in essi.
• Quando compilo il codice reale, ho commenti che spiegano in inglese cosa sto facendo. (Probabilmente ne avranno bisogno se è così complicato che devo prima scrivere uno pseudo codice).

Sui diagrammi di flusso

Il codice in genere cambia così tanto che i diagrammi di flusso non sono utili tranne per la progettazione o la documentazione di architettura più ampia e più estesa a livello di sistema. In questi casi, eseguirò semplicemente un diagramma per ottenere l'essenza delle cose o per mostrarlo a qualcun altro nella squadra. A meno che tu non abbia davvero bisogno di un diagramma di flusso per aiutarti a capire, non hai davvero bisogno che loro "facciano" il software nel modo giusto. Al giorno d'oggi, ci sono molti plugin per IDE che genereranno diagrammi di flusso dal codice stesso, così come diagrammi di classe e altri (e viceversa `). L'unico momento in cui avresti bisogno di fare un diagramma di flusso estremamente accurato è se non riesci a mantenere l'intera architettura e come le cose funzionano nella tua testa in una sola volta e devi parlare attraverso qualcosa di visivo per catturare i nodi.

Generalmente non scrivo diagrammi di flusso mentre sto lavorando a progetti personali (poiché i progetti non sono molto grandi) e la maggior parte degli input, degli output e dei processi sono chiari.

ma poiché inizierai a lavorare su grandi progetti complessi con diverse fonti di input, file flat, database, interfacce manuali, ecc. sono utili.

Ti consiglierei di scrivere codice pseudo e digram UML poiché questi strumenti ti aiuteranno a trovare classi, metodi, ecc. Migliori A volte mentre scrivi pseudo codice troverai modi diversi e più efficienti per risolvere un programma.

Lo pseudo codice serve a rappresentare rapidamente un'idea per coloro che comprendono almeno le basi del codice. I diagrammi di flusso stanno disegnando belle immagini per tutti gli altri per capire la stessa cosa.

I diagrammi di flusso vengono spesso utilizzati a scopo di documentazione poiché molte persone diverse utilizzano che la documentazione e i diagrammi di flusso sono più facili da seguire rispetto allo pseudo codice per i non programmatori. In un progetto su cui stai lavorando, attenersi allo pseudo codice va bene perché è molto più utile e molto più facile da creare poiché un editor di testo è tutto ciò di cui hai bisogno.

I diagrammi di flusso sono un alto livello di astrazione che ti consentono di pianificare come dovrebbero procedere le cose, ad esempio

se x muore y vince

Non hanno bisogno di dipendere da come stai progettando il programma in termini di classi e metodi, d'altro canto lo pseudo codice fornisce un livello inferiore di astrazione (anche se dipende davvero)

if (isdead (s)) y.win ()

pertanto lo pseudo codice può ora essere tradotto in un vero programma in base alla lingua che si sta utilizzando.

Per un gioco consiglierei di usare prima un diagramma di flusso, quindi progettare le classi e i metodi, scrivere lo pseudo codice e infine convertirlo in un programma

Vorrei considerare la natura del codice che stai scrivendo. Se è:

1. Altamente iterativo / ricorsivo
2. Si ramifica in modi complicati
3. Implementato in diversi sistemi, che si desidera rappresentare

Nei primi due casi, lo pseudocodice diventa progressivamente più difficile da leggere rispetto a un diagramma di grandi dimensioni. D'altra parte, il codice per lo più lineare rende diagrammi incredibilmente noiosi che rendono il processo più difficile da capire a causa di quanto lo fa esplodere.

Per il terzo caso, i diagrammi di flusso sono migliori nel rappresentare i processi che attraversano i confini del sistema e rappresentano l'intero processo.

1. Dovresti usare qualunque cosa ti senta a tuo agio. Detto questo, la mia impressione è che i diagrammi di flusso non siano molto utilizzati per delineare il controllo del programma in questi giorni; per prima cosa, in genere non sono strutturati, rispetto allo pseudocodice. È più comune usare diagrammi di dipendenza di classe come UML, per descrivere la tua architettura a un livello molto più alto. Inoltre, se l'applicazione ha una macchina a stati, è essenziale disegnare un diagramma a macchina a stati (simile a un diagramma di flusso).
2. Penso che tu abbia ragione qui. Un modo di lavorare è quello di scrivere il tuo pseudocodice come commenti nel tuo file sorgente per cominciare e inserire tra loro le linee di implementazione effettive.
3. Ancora una volta, usa tutto ciò che ti senti a tuo agio. Se non sei sicuro, provali entrambi; Mi aspetto che la tua pratica converga rapidamente su ciò che ti è più utile. Personalmente non trovo utili i diagrammi di flusso a meno che non stia cercando di districare un ordine di esecuzione particolarmente complicato.

Perché scrivere pseudo codice quando è possibile scrivere Java? Ho scoperto che Java, un buon IDE e Javadoc sono il modo più semplice per cogliere un problema di programmazione - almeno orientato agli oggetti . (E un gioco arcade dovrebbe essere OO.) Il linguaggio è stato progettato da zero per questo. È semplice e diretto. (Troppo semplice per molti scopi, forse, ma la cosa migliore che ho visto per questo.) L'ipertesto nel Javadoc e, tramite un IDE, nel codice stesso rende un "diagramma" più comprensibile di quanto tu possa attingere anche un grande foglio di carta. Il codice Java è semplice come qualsiasi pseudo codice e molto più rigoroso. E una volta che hai "diagrammato" e "pseudo" codificato, il programma verrà effettivamente eseguito!

Potresti usare un diagramma di flusso se ti stai davvero confondendo con le istruzioni if ​​e stai cercando di capirlo. O se stai cercando di capire un ciclo, vedi l'effetto dei contatori. Se stai imparando, può essere di grande aiuto.

Può sembrare un po 'restrittivo perché devi mettere brevi dichiarazioni in scatole. E se il tuo programma è molto lineare e i tuoi loop e if sono banali, allora non vedo nulla.

Lo pseudocodice è utile per progettare un programma, senza la distrazione di dover ottenere la sintassi corretta e senza la mancanza di respiro che alcune lingue possono coinvolgere. Il fatto che sia più veloce da scrivere semplifica anche la riprogettazione del codice. E puoi essere conciso come desidera la tua mente, è piacevole scrivere, richiede meno sforzo mentale per farlo funzionare (come nessun o molto meno debug) e più capacità di concentrarsi sul quadro generale e sul design.

Quindi, utile per te stesso.

Possono anche essere usati per comunicare con gli altri.