Quando dovrei usare lo pseudocodice invece del diagramma di flusso?

I diagrammi di flusso e gli pseudocodi 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 sono un livello di astrazione più elevato, utilizzato prima di scrivere pseudocodice o documentazione.

I diagrammi di flusso hanno, a mio parere, due forti vantaggi rispetto allo pseudocodice: in primo luogo, sono grafici. Molte persone non tecniche hanno una strong paura del testo strutturato, ma non delle descrizioni grafiche, quindi i diagrammi di flusso saranno più piacevoli con loro. In secondo luogo, i diagrammi di flusso sono molto più efficaci nell'esprimere metarecognanze come mostrare la linea principale di esecuzione rispetto ai rami.

Le tue domande in dettaglio:

1. Per un problema davvero complicato, prima dovresti 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 unibile con il codice reale. Steve McConnell, ad esempio, raccomanda vivamente di scrivere prima i metodi in 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. I diagrammi di flusso non banali indicano una logica complessa, che dovrebbe essere evitata a caro prezzo.

On Pseudo Code

Per essere onesti, non uso molto lo pseudocodice. In genere è più veloce scrivere semplicemente il codice, così quando ho finito con il mio codice, è un codice reale. Ci sono alcuni casi in cui lo pseudo codice può essere utile, ma in genere stai lavorando su qualcosa di molto complesso e solo cercando di rompere la struttura di un metodo o qualcosa del genere. In questi casi, utilizzo i commenti nel mio IDE per disporre la struttura finché non ottengo le cose giuste. Quindi, entro e scrivo il codice reale nei commenti. Questo mi aiuta a fare alcune cose:

• Riesco a vedere le aree che ho e non ho implementato leggendo i commenti e vedendo evidenti lacune in essi.
• Quando inserisco il codice reale, ho commenti che spiegano in inglese cosa sto facendo. (Probabilmente ne avranno bisogno se è così complicato da dover scrivere prima uno pseudo codice).

Su diagrammi di flusso

Il codice di solito cambia così tanto che i diagrammi di flusso non sono utili se non per una progettazione o documentazione di architettura più ampia e più sistemica. In questi casi mi limiterò a scrivere un diagramma per ottenere il succo delle cose o per mostrarlo a qualcun altro della squadra. A meno che tu non abbia davvero bisogno di un diagramma di flusso che ti aiuti a capire, allora non hai davvero bisogno di loro per "fare" il software giusto. Oggigiorno, ci sono molti plug-in per IDE che generano diagrammi di flusso dal codice stesso, così come diagrammi di classe e altri ( e viceversa '). L'unica vera volta in cui avresti bisogno di fare un diagramma di flusso molto accurato è se non riesci a mantenere l'intera architettura e come le cose funzionano nella tua testa in una volta e hai bisogno di parlare attraverso qualcosa di visivo per prendere dei 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 progetti complessi complessi con diverse sorgenti di input, file flat, database, interfacce manuali, ecc. sono utili.

Ti consiglierei di scrivere Pseudo codice e digram UML in quanto questi strumenti ti aiuteranno a trovare classi migliori, metodi, ecc. Talvolta mentre scrivi lo pseudo codice troverai modi diversi e più efficienti per risolvere un programma.

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

I diagrammi di flusso sono spesso usati a scopo di documentazione perché molte persone diverse usano quella documentazione ei diagrammi di flusso sono più facili da seguire rispetto allo pseudo codice per i non programmatori. In un progetto su cui stai lavorando da solo, è 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

if x dies y wins

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

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

quindi lo pseudo codice può ora essere tradotto in un programma reale basato sulla lingua che stai usando.

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

Considererei la natura del codice che stai scrivendo. Se è:

1. Altamente iterativo / ricorsivo
2. Succursali 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 grande diagramma di immagine. D'altra parte, il codice che è per lo più lineare rende i 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 più adatti a rappresentare i processi che attraversano i confini del sistema e rappresentano l'intero processo.

1. Dovresti usare qualunque cosa ti senti 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, sono in genere non strutturati, rispetto allo pseudocodice. È più comune utilizzare diagrammi di dipendenza dalla classe come UML per descrivere la tua architettura ad un livello molto più alto. Inoltre, se l'applicazione ha una macchina a stati, è essenziale disegnare un diagramma della macchina a stato (simile a un diagramma di flusso)
2. Penso che tu abbia ragione qui. Un modo per lavorare è scrivere il tuo pseudocodice come commenti nel file sorgente per iniziare, e inserire le linee di implementazione effettive tra di loro.
3. Ancora una volta, usa quello che ti senti a tuo agio. Se non sei sicuro, provale 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 puoi scrivere Java? Ho trovato Java, un buon IDE e Javadoc sono il modo più semplice per cogliere un problema di programmazione, almeno uno 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 in Javadoc e, tramite un IDE, nel codice stesso creano un "diagramma" più comprensibile rispetto a quello che potresti disegnare anche un grande foglio di carta. Il codice Java è semplice come qualsiasi pseudo codice e molto più rigoroso. E una volta che hai il codice "diagrammed" e "pseudo", il programma verrà effettivamente eseguito!

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

Può sembrare un po 'restrittivo perché è necessario inserire brevi istruzioni in riquadri. E se il tuo programma è molto lineare e i tuoi loop e ifs sono banali, allora non ne vedo l'utilità.

Lo pseudocodice è utile per progettare un programma, senza la distrazione di dover sintonizzare correttamente la sintassi, e senza la prolissità che alcune lingue possono coinvolgere. Il fatto che sia più veloce da scrivere facilita anche la riprogettazione del codice. E puoi essere così conciso come desideri la tua mente, è piacevole da scrivere, richiede meno sforzi mentali per farlo funzionare (come no o molto meno debugging), e una maggiore capacità di concentrarsi sul grande quadro e sul design.

Quindi, utile per te.

Possono anche essere usati per comunicare con altri.