Si dovrebbe usare uno pseudocodice prima della vera codifica?

Scrivere lo pseudocodice prima della codifica è certamente meglio della semplice programmazione senza pianificazione, ma è ben lungi dall'essere una buona pratica. Lo sviluppo basato sui test è un miglioramento.

Ancora meglio è analizzare il dominio del problema e progettare soluzioni usando tecniche come storie utente, casi d'uso, carte CRC, diagrammi, come sposati da metodologie come Cleanroom, RUP, Lean, Kanban, Agile, ecc.

Comprendere a fondo la natura del problema e i componenti che utilizzi per implementare la soluzione è il principio alla base delle best practice.

Uso i commenti come una sorta di pseudo codice di altissimo livello, in quanto scrivo i commenti prima di scrivere il codice. Trovo che pensare all'intero problema, anche ad alto livello, migliori considerevolmente il mio codice.

No, non pseudo-code prima

Questo è troppo sovraccarico. Stai facendo il lavoro di scrivere la logica senza nessuno dei benefici. Suggerirei comunque uno dei seguenti:

1. Prototipo nella lingua che verrà spedito con (AKA Scrivi uno da buttare via )
2. Diagrammi di architettura con frammenti di codice per testare ipotesi / progetti chiave
3. Test Driven Development in cui scrivi prima la tua interfaccia / struttura del codice, seguita da test, seguita dall'implementazione del codice.

Tutti e tre di questi ti spostano direttamente verso la tua soluzione, a differenza dello pseudo-codice. Personalmente tendo ad usare le tecniche 1 o 2 a seconda delle dimensioni del team. Per le squadre più piccole (ad esempio 5 persone o meno), la prototipazione funziona molto bene. Per i team più grandi che hanno più gruppi di sviluppatori che lavorano in parallelo, ho trovato che la documentazione prodotta in anticipo dalla tecnica 2 funziona bene perché ti dà qualcosa da discutere in anticipo e ti aiuta a definire meglio i limiti dei componenti. Sono sicuro che anche TDD funzionerà molto bene, ma devo ancora lavorare su un team impegnato in questo processo.

Secondo me, lo pseudo-codice ha solo due scopi validi:

(1) Per programmare gli studenti che hanno bisogno di apprendere i concetti di modularità e algoritmi, ma non sono ancora fluenti in un linguaggio di programmazione.

(2) Comunicare come funzionerà qualcosa a una persona non tecnica, o solo per convenienza in una riunione di tipo lavagna bianca.

Lo pseudo-codice è un approccio suggerito? Per i programmatori principianti, dico di sì. Aiuta il nuovo programmatore a imparare come tradurre un problema in codice senza preoccuparsi della sintassi esatta della lingua. Questo dà forma al processo del pensiero e può aiutare ad invertire abitudini utili (e suppongo anche cattive abitudini). Questo è il motivo per cui è usato così tanto nelle scuole.

È praticato nell'industria? Nella mia esperienza, no. Nessuno ha il tempo di sbrogliare il progetto tra la documentazione (requisiti, specifiche, schede, casi d'uso o qualsiasi altra cosa che usano) e il codice effettivo. Generalmente si presume che un pensiero sufficiente sia già stato inserito nel problema prima che il semaforo verde codifichi. A quel punto, la codifica del progetto è più importante dell'aggiunta di un ulteriore livello di preparazione del progetto.

Raccomando senz'altro pseudocodice. Ti aiuta a chiarire cosa stai per fare e identificare elementi che potresti aver dimenticato o potenziali problemi. È molto più facile / veloce risolvere il tuo codice quando è ancora in fase di pianificazione, piuttosto che aspettare di averne già codificato gran parte.

Lo pseudocodice può essere utile se non conosci la lingua o se devi cambiare i contesti mentali. Nella rara occasione in cui scrivo pseudocodice, è sulla carta. A volte basta staccare le mani dalla tastiera e scarabocchiare sulla carta può aiutare a superare un blocco mentale.

Ma come parte formalizzata del processo di sviluppo? Non c'è modo. È uno strumento sporadicamente utile per gli individui. Ci sono modi migliori per "sapere cosa stai scrivendo prima di scriverlo", come:

1. definizione del contratto (condizioni pre / post / invarianti) del metodo prima di iniziare
2. TDD
3. 1 e 2 combinati (scrivere test per eseguire il contratto)

Suggerirei anche che ottenere qualsiasi tipo di approvazione prima di iniziare a scrivere il codice può causare molto più fastidio di quanto valga. Le revisioni del progetto (pre-implementazione) possono essere utili, ma devono essere a un livello superiore rispetto ai singoli algoritmi.

Non sono d'accordo con le risposte precedenti e dico di no, ma con un avvertimento: puoi liberarti di psuedocode solo se hai febbrilmente dedicato al refactoring del tuo codice per affrontare i problemi che emergono. Psuedocode è, nella sua essenza, un modo per definire il codice prima di definire il codice; è un'astrazione superflua in molte circostanze e dal momento che il tuo codice non sarà mai perfetto la prima volta (e probabilmente non seguirà il progetto di psuedocode fino al completamento), mi sembra estraneo.

Se stai scrivendo COBOL o C, lo pseudocodice potrebbe essere utile perché scrivere il codice effettivo richiederà molto più tempo e, se riesci a verificare i tuoi algoritmi / requisiti dallo pseudocodice, puoi risparmiare un po 'di tempo.

Nei linguaggi più moderni, lo pseudocodice non ha molto senso. Ciò che funzionerebbe meglio è la scrittura di stub di metodi e la compilazione della logica di livello superiore e di tutti i dettagli necessari per verificare l'algoritmo e i requisiti, il tutto nel codice reale. È quindi possibile mostrare il codice al lead del team per l'approvazione e avere già avviato il codice reale.

Le uniche volte in cui ho usato pseudocodice negli ultimi 10 anni sono in intervista quando stiamo lavorando su una lavagna e la lingua particolare non ha importanza.

È certamente utile per parlare attraverso un processo / algoritmo in termini sciolti senza impantanarsi con la sintassi. Per esempio. scrivere una classe C ++ che abbia proprietà C #, solo per illustrare il punto.

Ha il suo "posto", ma dovrebbe essere usato solo dove necessario (è un lavoro che butterai via) e certamente non fa parte di un processo formale, a meno che tu non abbia degli standard di tipo ISO che insistono su di esso.

Per me stesso e per le persone con cui ho lavorato negli ultimi anni, lo pseudocodice è praticamente diventato un codice reale non perfettamente perfetto. a meno che non lavori con molte lingue contemporaneamente, la maggior parte delle persone sembra iniziare a pensare al modello generale della loro lingua principale. Ho lavorato nei negozi di .net per un po ', quindi la lavagna della maggior parte delle persone scarabocchiati in ufficio tende ad assomigliare a vb o c # con alcuni segni di punteggiatura mancanti.

L'esercizio è ancora prezioso quando si discutono opzioni e cose del genere, ma il bit agnostico della lingua tende ad allontanarsi man mano che passi più tempo con alcune lingue.

Sempre di più, lo pseudocodice è scritto graficamente con strumenti come UML. Ad esempio, prova yUML .

an online tool for creating and publishing simple UML diagrams. It's makes it really easy for you to:

• Embed UML diagrams in blogs, emails and wikis.
• Post UML diagrams in forums and blog comments.
• Use directly within your web based bug tracking tool.
• Copy and paste UML diagrams into MS Word documents and Powerpoint presentations...

...yUML saves you time. It's designed to for those that like to create small UML diagrams and sketches.

Without yUML, creating a UML diagram might involve loading up a UML tool, creating a diagram, giving it a name, fiddling with layout, exporting it to bitmap, and then uploading it online somewhere. yUML doesn't make you do any of that...

Ottimo lavoro. Hai iniziato una buona discussione Da parte mia, scrivevo pseudo-codici mentre stavo imparando a programmare per capire i vari loop e algoritmi. Questo era più di un decennio e mezzo fa. A quei tempi, anche i linguaggi di programmazione non erano molto potenti ... e la programmazione guidata dagli eventi era futura. Ora con 4GL e 5GL, pensiamo nella lingua stessa piuttosto che in un inglese semplice. Quando pensiamo a un problema, pensiamo in termini di oggetti e operazioni. E fino a quando non sarà un algo complesso, scrivere pseudo-codici (o P-S-E-U-DO-Codes, sto scherzando) non ha alcun senso. Meglio, rappresenta la soluzione in modo grafico.

Dipende dal linguaggio utilizzato e dalla familiarità con esso.

Molti linguaggi moderni come Python o Java sono già così vicini allo pseudocodice che scrivere uno pseudocodice ad hoc prima è uno spreco, IMHO. È meglio farlo subito utilizzando l'approccio indicatore del tracciante .

È un accordo diverso se stai realizzando oggetti di basso livello, vicini al metal o non ti senti ancora a tuo agio con la lingua che stai utilizzando. Quindi lo pseudocodice può sicuramente essere utile.

Ci sono un paio di circostanze in cui lo pseudocodice tende a scoppiare nel mio lavoro, che è nel mondo accademico dove la programmazione tende ad essere usata come uno strumento o il "e ora lo risolviamo" riempiendo nel mezzo di un progetto :

1. Quando il codice sarà più controproducente per una reale comprensione di ciò che accadrà di quanto lo sarà lo pseudo-codice. SAS, ad esempio, occuperà metà della lavagna eseguendo alcune attività di programmazione abbastanza semplici. Vedi anche C, di cui hanno parlato alcuni altri poster.
2. Con un sacco di analisi dei dati e la codifica delle statistiche, tende ad essere un sacco di armeggiare con il codice come vengono generati i risultati. Lo pseudocodice è un po 'più facile da usare perché "qui sta un processo avanti e indietro, se la trama diagnostica non sembra corretta, prova X".
3. Gli studenti imparano molti diversi linguaggi di programmazione. Ad esempio, tra le persone che conosco, un problema di statistiche potrebbe essere analizzato in SAS, R o Stata. Qualcosa che richiede qualcosa di più vicino alla programmazione tradizionale potrebbe essere fatto in R, Matlab, C, C ++, Java, Python ... dipende davvero da quale particolare studente sta implementando il programma, e per quale scopo. Ma è ancora utile per il popolo Java e il popolo Python e il popolo Matlab avere un'idea comune di ciò che fanno gli altri, e come funziona approccio , piuttosto che il codice stesso.

Questo non è un tipo si / no. Piuttosto, ci si dovrebbe chiedere quando usare lo pseudo-codice. È importante comprendere il problema prima di progettare una soluzione ed è importante avere una visione chiara della soluzione prima di implementarla. Lo pseudo-codice può essere utilizzato in uno di questi passaggi:

1. Quando si definisce il problema, è normale annotare casi d'uso, a volte usando sequenze di azioni.
2. Quando si progetta una soluzione. I diagrammi delle classi sono belli, ma descrivono solo la parte "statica", cioè i dati. Per la parte dinamica, non appena si ha a che fare con un ciclo e dati non banali, trovo che lo pseudo-codice sia il miglior metodo disponibile. Le alternative grafiche includono le macchine a stati (buone per il flusso di controllo complesso con pochi dati) e i diagrammi del flusso di dati (utile per flussi semplici con dati complessi).
3. Quando si implementa la soluzione (o poco prima). Alcuni linguaggi di programmazione sono difficili da leggere (pensare, assemblare). Una rappresentazione alternativa può essere utile in questo caso. Se non conosci le lingue, vale la pena farlo.

Viene usato anche lo pseudo-codice che in realtà è il codice corretto in un linguaggio di alto livello, solitamente viene chiamato prototipazione.

Oltre a raggiungere la comprensione, lo pseudo-codice è anche un bene per la comunicazione.

Se ti stai chiedendo se dovresti usare lo pseudo-codice su base regolare, sono personalmente contrario a tutti i tipi di regole rigide. Questo può facilmente trasformarsi in una noiosa perdita di tempo se usata per problemi banali che tutti nel team comprendono. L'uso di pseudo-codice per le specifiche che mantieni durante la vita del progetto può anche essere costoso e offrire poco valore.