Când aș folosi pseudocod în loc de diagramă?

Fl diagrame și pseudocod au adesea același nivel de expresivitate, dar diferă prin liniarizare. Pseudocodul este liniar (adică o secvență de linii cu instrucțiuni), o diagramă de flux nu este. Prin urmare, diagramele de flux sunt un nivel de abstractizare mai mare, utilizate înainte de a scrie pseudocod sau pentru documentare.

Diagramele de flux au, în opinia mea, două avantaje puternice față de pseudocod: În primul rând, sunt grafice. Multe persoane non-tehnice au o teamă puternică de text structurat, dar nu de descrieri grafice, astfel încât diagramele de flux vor sta mult mai frumos cu ele. În al doilea rând, diagramele de flux sunt mult mai bune în exprimarea meta-considerațiilor, cum ar fi arătarea liniei principale de execuție, spre deosebire de ramuri.

Întrebările dvs. în detaliu:

1. Pentru o într-adevăr complicată problemă, ați folosi diagramele de flux mai întâi, apoi pseudocodul. Ambele sunt opționale atunci când vă simțiți suficient de sigur.
2. Da, pseudocodul are avantajul că poate fi combinat cu codul real. Steve McConnell, de exemplu, recomandă cu tărie mai întâi să scriem metode în pseudocod și apoi să lăsăm pseudocodul în cod ca comentarii.
3. Am simțit întotdeauna că nevoia de a desena un diagramă în timpul proiectării arată o partiție insuficientă a problemei tale. Diagramele non-banale indică o logică complicată, care ar trebui evitată cu costuri mari.

Comentarii

• Diagramele de flux sunt, de asemenea, o modalitate excelentă pentru a vă asigura că fiecare punct de decizie definește acțiunile pentru calea (camele) mai puțin frecvente, precum și cea mai comună. Acest lucru vă asigură că veți ști ce să faceți atunci când aprobarea este refuzată sau comanda este anulată! Există adesea mai multe erori în cazurile marginale, deoarece oamenii uită să le facă sau să le facă în grabă în timpul QA atunci când testarea le găsește.

Pe Pseudo Code

Pentru a fi sincer, nu folosesc prea mult pseudocodul. De obicei, este mai rapid să scrii doar codul, astfel încât, când am terminat cu codul meu, este codul propriu-zis. Există unele cazuri în care pseudo-codul poate fi util, dar în general lucrați la ceva foarte complex și încercați doar să descompuneți structura unei metode sau ceva. În aceste cazuri, folosesc comentarii în IDE-ul meu pentru a stabili structura până când fac lucrurile corecte. Apoi intru și scriu codul real în comentarii. Acest lucru mă ajută să fac câteva lucruri:

• Pot vedea zonele pe care le am și nu le-am implementat citind comentariile și văzând lacune evidente în ele.
• Când completez codul real, am comentarii care explică în limba engleză ce fac. (Probabil că vor avea nevoie de el dacă este atât de complicat că trebuie să scriu mai întâi pseudo-cod).

Pe diagramele de flux

Codul se modifică de obicei atât de mult încât diagramele de flux nu sunt utile, cu excepția arhitecturii mai mari, la nivelul întregului sistem proiectare sau documentare. În aceste cazuri, voi pur și simplu o tablă albă pentru a obține esența lucrurilor sau pentru a le arăta altcuiva din echipă. Dacă nu aveți nevoie într-adevăr de o diagramă pentru a vă ajuta să înțelegeți, atunci nu aveți nevoie de ei pentru a „face” software-ul dreapta. În zilele noastre, există o mulțime de plugin-uri pentru IDE care vor genera diagrame din codul în sine, precum și diagrame de clasă și altele (și invers `). Singurul timp real de care ai avea nevoie pentru a face o diagramă foarte precisă este dacă nu poți păstra întreaga arhitectură și modul în care lucrurile funcționează în capul tău dintr-o dată și trebuie să vorbești prin ceva vizual pentru a prinde greșeli.

În general, nu scriu organigramă în timp ce lucrez la proiecte personale (deoarece proiectele nu sunt prea mari) și majoritatea intrărilor, ieșirilor și proceselor sunt clare.

dar pe măsură ce veți începe să lucrați la proiecte mari complexe cu surse de intrare diferite, fișierele plate, bazele de date, interfețele manuale etc. diagramele de flux sunt la îndemână.

Aș recomanda scriind coduri Pseudo și digrame UML, deoarece aceste instrumente vă vor ajuta să veniți cu clase, metode mai bune etc. Uneori, în timp ce scrieți pseudo cod, veți găsi modalități diferite și mai eficiente de a rezolva un program.

Pseudo codul este reprezentarea rapidă a unei idei către cei care înțeleg cel puțin elementele de bază ale codului. pentru a înțelege același lucru.

Diagramele de flux sunt adesea utilizate în scopuri de documentare, deoarece mulți oameni folosesc documentația și diagramele de flux sunt mai ușor de follow decât pseudo-cod pentru non-programatori. Într-un proiect la care lucrați singur, lipirea cu pseudo-cod este în regulă, deoarece este mult mai utilă și mult mai ușor de creat, întrucât un editor de text este tot ceea ce aveți nevoie.

luați în considerare natura codului pe care îl scrieți. Dacă este:

1. Foarte iterativ / recursiv
2. Sucursale în moduri complicate
3. Implementat în mai multe sisteme, pe care doriți să le reprezentați

În primele două cazuri, pseudocodul devine progresiv mai greu de citit decât o diagramă mare. Pe de altă parte, codul care este în cea mai mare parte liniar face diagrame incredibil de plictisitoare care fac procesul să fie mai greu de înțeles datorită cât de mult îl aruncă. treceți limitele sistemului și reprezentați întregul proces.

1. Ar trebui să utilizați orice vă simțiți confortabil. Acestea fiind spuse, impresia mea este că diagramele de flux nu sunt folosite intens pentru a schița controlul programului în aceste zile; pentru un lucru, acestea sunt de obicei nestructurate, comparativ cu pseudocodul. Este mai frecvent să folosiți diagrame de dependență de clasă, cum ar fi UML, pentru a descrie arhitectura dvs. la un nivel mult mai înalt. De asemenea, dacă aplicația dvs. are o mașină de stare, este esențial să desenați o diagramă de mașină de stare (de tip diagramă de flux).
2. Cred că aveți dreptate aici. O modalitate de a lucra este să scrieți pseudocodul ca comentarii în fișierul sursă pentru a începe și să introduceți liniile de implementare efective între ele.
3. Din nou, folosiți orice vă simțiți confortabil. Dacă nu sunteți sigur, încercați-le pe amândouă; mă aștept ca practica dvs. să convergă rapid către ceea ce vă este cel mai util. Personal, nu consider că diagramele de flux sunt utile decât dacă încerc să descâlcesc o ordine de execuție deosebit de complicată.

De ce să scriu pseudo cod când poți scrie Java? Am găsit Java, un IDE bun și Javadoc este cel mai simplu mod de a înțelege o problemă de programare – cel puțin una orientată spre obiect . (Și un joc arcade ar trebui să fie OO.) Limbajul a fost conceput de la bază pentru asta. Este simplu și direct. (Prea simplu pentru multe scopuri, poate, dar cel mai bun lucru pe care l-am văzut pentru asta.) Hipertextul din Javadoc și, printr-un IDE, din codul în sine, fac o „diagramă” mai ușor de înțeles decât ai putea trage chiar o foaie mare de hârtie. Codul Java este la fel de simplu ca orice pseudo cod și mult mai riguros. Și odată ce l-ai „diagramat” și „pseudo” codat, programul va rula de fapt!

Comentarii

• Java și altele pot fi îndepărtate. ” public static void main .. ” sau ” system.out.println ” sau identificatori lungi cu notație camelback, cu vânt lung acolo.n apoi excepții care au prins 2b .. Și apelarea oricărei biblioteci poate fi îndepărtată. Îmi amintesc că acum 10 ani am deschis un fișier. ceva de genul nou BufferedReader (nou InputStreamReader (System.in)); aparent mai ușor acum mkyong.com / java / … Dar, într-adevăr, orice bibliotecă pe care o numiți ar putea fi lungă, nu ca un pseudocod care poate fi la fel de concis pe cât vă puteți imagina
• de asemenea, în java sau orice altă limbă, dați greșeli la compilare. nimic din toate acestea cu pseudocod. ajungi să te concentrezi pe design fără distragere. Comentariile despre pseudocod pot fi mult mai scurte, deoarece pseudocodul este mai clar pentru minte, deoarece ‘ se află din minte. ‘ nu ești limitat doar prin a gândi într-o singură limbă și s-ar putea să vezi că voi ‘ vei folosi această altă limbă. Este ‘ mai rapid și mai puțin dureros de scris (nu sunt necesare compilări – chiar și cei foarte fluenți obțin erori de compilare) și, prin urmare, mai puțin timp pentru a scrie face mai ușor reproiectarea.
• @barlop: Funcționează pentru mine, dar s-ar putea să nu funcționeze pentru toată lumea. Las o mulțime de cod (” BufferedReader „, de exemplu) în afara claselor mele până când am nevoie de el sau trebuie să știu dacă am poate face să funcționeze. Chiar și atunci când îl am, ‘ s-a ascuns frumos din clasele pe care nu ‘ nu trebuie să le privesc atunci când se ia în considerare proiecta. Erorile compilatorului sunt ușor de remediat și pot preveni defectele majore de proiectare, cum ar fi utilizarea clasei greșite într-un punct în care puteți ‘ chiar obține o instanță a clasa potrivită. Recunosc, am ” proiectat ” astfel încât să poată numai să fie scris în Java, dar OP utilizează Java.
• așa că spuneți că doriți să deschideți un fișier, vedeți cum este pseudocodul openfile (” c: \ blah \ file „) este mai scurt decât java pentru ao face? sau că tipărirea ” dfdfd ” este mai scurtă decât java pentru a o face? ‘ nu am făcut (încă) pagini de pseudocod și clase multiple. parțial ‘ cos Nu am ‘ scrise programe mari în epoci b) parțial ‘ cos Nu ‘ nu cred că aș crede, cred că ‘ aș scrie un pseudocod, apoi îl voi pune în aplicare. Orice alt pseudocod, dacă există, ar fi de nivel superior. S-ar putea să am o listă cu toate clasele și metodele, inclusiv constructorii. Deci știu ce clase sunt și ce pot obține o instanță a acestuia ..
• așa că nu aș fi ‘ în situația de a folosi clasa greșită dar oricum, dacă este ‘ programul meu, ‘ aș fi notat în notele mele ce clasă este ceea ce .. clasele sunt frumoase nivel inalt. Am ‘ am o notă despre faptul că, dacă nu îmi pot aminti ‘. Și pseudocodul se referă la ceea ce înseamnă cineva, deci dacă ai vrut să creezi o instanță din clasa bla și ai scris bleh, atunci ‘ este doar o greșeală de scriere, dar nu ‘ nu vă împiedică designul. (dacă ‘ scrii pentru tine ‘ pentru că știi ce vrei să spui și l-ai folosit ca un bla).

Puteți utiliza o diagramă de flux dacă vă confundați cu afirmațiile if și încercați să înțelegeți acea. Sau dacă încercați să înțelegeți o buclă, vedeți efectul contoarelor. Dacă învățați, vă poate ajuta foarte mult.

Se poate simți un pic restrictiv „pentru că trebuie să puneți afirmații scurte în casete. Și dacă programul dvs. este foarte liniar, iar buclele și if-urile dvs. sunt banale, atunci nu văd nici un folos.

Pseudocodul este util pentru proiectarea unui program. fără distragerea necesității de a obține sintaxa corectă și fără lungimea pe care o pot implica unele limbi. Faptul că este mai rapid de scris face, de asemenea, mai ușoară reproiectarea cod. Și poți fi la fel de concis pe cât îți dorește mintea, este plăcut să scrii, necesită mai puțin efort mental pentru a-l face să funcționeze (la fel de mult sau mai puțin depanare) și mai multă abilitate de a te concentra asupra imaginii generale și a designului.

Deci, este util pentru dvs.

Ele pot fi, de asemenea, utilizate pentru comunicarea altora.