Quando dovrei usare lo pseudocodice invece del diagramma di flusso?

Fl I grafici e lo 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 non lo è. Pertanto, i diagrammi di flusso sono un livello di astrazione più alto, usato prima di scrivere lo pseudocodice o per la 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 forte paura del testo strutturato, ma non delle descrizioni grafiche, quindi i diagrammi di flusso saranno molto più belli con loro. In secondo luogo, i diagrammi di flusso sono molto più bravi nellesprimere meta-considerazioni come mostrare la linea principale di esecuzione rispetto ai rami.

Le tue domande in dettaglio:

1. Per un problema, dovresti usare prima 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, consiglia 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. Diagrammi di flusso non banali indicano una logica contorta, che dovrebbe essere evitata a costi elevati.

Commenti

• Anche i diagrammi di flusso sono ottimi per assicurarsi che ogni punto di decisione definisca le azioni per i percorsi meno comuni oltre che per quelli più comuni. Ciò ti aiuta ad assicurarti di sapere cosa fare quando lapprovazione viene negata o lordine viene annullato! Ci sono spesso più bug nei casi limite perché le persone si dimenticano di farli o di eseguirli in fretta durante il QA quando i test li trovano.

Su pseudo codice

Ad essere onesto, non uso molto lo pseudocodice. In genere è più veloce scrivere solo il codice, così quando ho finito il mio codice, è il codice effettivo. Ci sono alcuni casi in cui lo pseudo codice può essere utile, ma in genere stai lavorando su qualcosa di molto complesso e stai solo cercando di scomporre la struttura di un metodo o qualcosa del genere. In quei casi, utilizzo i commenti nel mio IDE per definire la struttura finché non riesco a sistemare le cose. Quindi, entro e scrivo il codice effettivo nei commenti. Questo mi aiuta a fare alcune cose:

• Posso vedere le aree che ho e non sono state implementate da 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 che devo scrivere prima uno pseudo codice).

Sui diagrammi di flusso

Il codice in genere cambia così tanto che i diagrammi di flusso non sono utili tranne che per unarchitettura più grande e più ampia progettazione o documentazione. In questi casi, mi limiterò a scrivere sulla lavagna un diagramma per ottenere lessenza delle cose o per mostrarlo a qualcun altro del team. A meno che tu non abbia davvero bisogno di un diagramma di flusso per aiutarti a capire, allora non hai davvero bisogno che “faccia” software giusto. Al giorno doggi, ci sono molti plug-in per IDE che generano diagrammi di flusso dal codice stesso, nonché diagrammi di classe e altri (e viceversa `). Lunico momento reale di cui hai bisogno per fare un diagramma di flusso veramente accurato è se non riesci a mantenere lintera architettura e come funzionano le cose nella tua testa contemporaneamente e hai bisogno di parlare attraverso qualcosa di visivo per catturare i nodi.

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

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

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

Lo pseudo codice serve a rappresentare rapidamente unidea a coloro che comprendono almeno le basi del codice. I diagrammi di flusso consentono di disegnare 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 e i diagrammi di flusso sono più facili da seguire di pseudo codice per non programmatori. In un progetto su cui stai lavorando da solo, 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 rappresentano un alto livello di astrazione e ti consentono di pianificare come dovrebbero procedere le cose, ad esempio

se x dies y wins

Non hanno bisogno di dipendere da come stai progettando il programma in termini di classi e metodi, pseudo codice daltra parte fornire un livello più basso di astrazione (sebbene in realtà dipenda)

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

così ora lo pseudo codice può essere tradotto in un programma effettivo in base alla lingua che stai utilizzando.

Per un gioco ti consiglio di utilizzare prima un diagramma di flusso, poi il design le classi e i metodi, scrivi pseudo codice e infine convertilo in un programma

Lo voglio d considera la natura del codice che stai scrivendo. Se è:

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

Nei primi due casi, lo pseudocodice diventa progressivamente più difficile da leggere rispetto a un diagramma a grande immagine. Daltra parte, il codice per lo più lineare rende diagrammi incredibilmente noiosi che in realtà rendono il processo più difficile da capire a causa di quanto lo fa saltare in aria.

Per il terzo caso, i diagrammi di flusso sono più bravi a rappresentare processi che attraversa i confini del sistema e rappresenta lintero 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 abbozzare il controllo del programma in questi giorni; per prima cosa, sono tipicamente non strutturati, rispetto allo pseudocodice. È più comune utilizzare diagrammi di dipendenza tra classi come UML, per descrivere la propria architettura a un livello molto più alto. Inoltre, se la tua applicazione ha una macchina a stati, disegnare un diagramma della macchina a stati (simile a un diagramma di flusso) è essenziale.
2. Penso che tu abbia ragione qui. Un modo per lavorare è scrivere il tuo pseudocodice come commenti nel tuo file sorgente per iniziare, e inserire le linee di implementazione effettive tra di loro.
3. Di nuovo, usa quello 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 puoi scrivere Java? Ho trovato Java, un buon IDE, e Javadoc è il modo più semplice per afferrare un problema di programmazione, almeno uno Object Oriented . (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.) Lipertesto nel Javadoc e, tramite un IDE, nel codice stesso creano un “diagramma” più comprensibile di quanto si possa disegnare anche un grande foglio di carta. Il codice Java è semplice come qualsiasi pseudo codice e molto più rigoroso. E una volta che lo avrai “schematizzato” e “pseudo” codificato, il programma verrà effettivamente eseguito!

Commenti

• java e altri possono essere prolissi. ” public static void main .. ” o ” system.out.println ” o identificatori lunghi con notazione a dorso di cammello, prolissi lì.n quindi eccezioni che avere 2b catturato .. E chiamare qualsiasi libreria può essere lungo senza fiato. Ricordo che 10 anni fa aprivo un file. qualcosa come new BufferedReader (new InputStreamReader (System.in)); apparentemente più facile ora mkyong.com / java / … Ma in realtà qualsiasi libreria che chiami potrebbe essere prolissa, non come lo pseudocodice che può essere conciso come puoi immaginare
• anche in java o in qualsiasi lingua, si riscontrano errori durante la compilazione. niente di tutto ciò con pseudocodice. puoi concentrarti sul design senza distrazioni. I commenti sullo pseudocodice possono essere molto più brevi in quanto lo pseudocodice è più chiaro alla mente poiché ‘ viene dalla mente. ‘ non sei limitato pensando in una sola lingua e potresti vedere che ‘ userò questaltra lingua. È ‘ più veloce e meno faticoso da scrivere (non sono necessarie compilazioni – anche gli errori di compilazione get molto fluidi) e quindi meno tempo per scrivere rende più facile riprogettare.
• @barlop: funziona per me, ma potrebbe non funzionare per tutti. Lascio molto codice (” BufferedReader “, ad esempio) fuori dalle mie classi finché non ne ho bisogno o devo sapere se ho può farlo funzionare. Anche quando ce lho, ‘ è ben nascosto nelle classi che ‘ non ho bisogno di guardare quando si considera in generale design. Gli errori del compilatore sono facilmente risolvibili e possono prevenire importanti difetti di progettazione, come luso della classe sbagliata in un punto in cui è possibile ‘ t anche ottenere unistanza del classe giusta. Lo ammetto, ho ” progettato ” software in questo modo che potrebbe solo essere scritto in Java, ma lOP sta usando Java.
• quindi dì che vuoi aprire un file, vedi come pseudocodice di openfile (” c: \ blah \ file “) è più corto del java per farlo? o che print ” dfdfd ” è più corto del java per farlo? ‘ non ho mai creato (ancora) pagine di pseudocodice e classi multiple. in parte ‘ perché non ‘ t scritto grandi programmi in età b) in parte ‘ così Non ‘ penso che lo farei, penso che ‘ scriverei qualche pseudocodice e poi lo implementerei. Qualsiasi altro pseudocodice, se presente, sarebbe di livello superiore. Potrei avere un elenco di tutte le classi e metodi inclusi i costruttori. Quindi so quali sono le classi e che posso ottenerne unistanza ..
• quindi ‘ non mi troverei in una situazione di utilizzo della classe sbagliata ma comunque, se ‘ è il mio programma, ‘ avrei scritto nelle mie note quale classe è cosa .. le classi sono belle alto livello. ‘ vorrei avere una nota al riguardo se non posso ‘ ricordarmela. E lo pseudocodice riguarda tutto ciò che si intende, quindi se intendevi creare unistanza della classe blah e hai scritto bleh, allora ‘ è solo un errore di battitura ma non ‘ t ostacola il tuo design. (se ‘ stai scrivendo per te stesso ‘ perché sai cosa intendi e lhai usato come un blah).

Potresti usare un diagramma di flusso se “ti senti davvero confuso dalle istruzioni if” e stai cercando di capire quello. Oppure, se stai cercando di capire un loop, guarda leffetto dei contatori. Se stai imparando può aiutare molto.

Può sembrare un po restrittivo “perché devi inserire brevi dichiarazioni in riquadri. E se il tuo programma è molto lineare e i tuoi cicli e se sono banali, allora non vedo alcuna utilità.

Lo pseudocodice è utile per progettare un programma. senza la distrazione di dover ottenere la sintassi giusta e senza la prolissità che alcuni linguaggi possono comportare. Il fatto che sia più veloce da scrivere rende anche più facile riprogettare codice. E puoi essere conciso quanto la tua mente desidera, è piacevole scrivere, richiede meno sforzi mentali per farlo funzionare (come nessun debug o molto meno) e più capacità di concentrarsi sul quadro generale e sul design.

Quindi, utili per te stesso.

Possono anche essere usati per comunicare con gli altri.