Milloin käytän pseudokoodia vuokaavion sijaan?

Fl yleiskaavioilla ja näennäiskoodeilla on usein sama ilmeikkyys, mutta ne eroavat toisistaan lineaarisuudessa. Pseudokoodi on lineaarinen (ts. Sarja viivoja ohjeiden kanssa), vuokaavio ei ole. Siksi vuokaaviot ovat korkeampi abstraktiotaso, joita käytetään ennen pseudokoodin kirjoittamista tai dokumentointiin.

Vuokaavioilla on mielestäni kaksi vahvaa etua pseudokoodiin nähden: Ensinnäkin, ne ovat graafisia. Monilla ei-teknisillä ihmisillä on voimakas pelko strukturoidusta tekstistä, mutta ei graafisista kuvauksista, joten vuokaaviot istuvat heidän kanssaan paljon mukavammin. Toiseksi vuokaaviot ilmaisevat paljon paremmin meta-näkökohtia, kuten näyttää pääsuorituslinja haarojen sijaan.

Kysymyksesi yksityiskohtaisesti:

1. Todella monimutkaiselle ongelma, käytät ensin vuokaavioita ja sitten pseudokoodia. Molemmat ovat valinnaisia, kun tunnet olosi riittävän turvalliseksi.
2. Kyllä, pseudokoodilla on se etu, että se voidaan yhdistää todelliseen koodiin. Esimerkiksi Steve McConnell suosittelee voimakkaasti kirjoitusmenetelmiä pseudokoodiin ja sen jälkeen pseudokoodin jättämisen koodiksi kommenteiksi.
3. Minusta tuntui aina, että tarve piirtää vuokaavio suunnittelun aikana osoittaa ongelmasi riittämätöntä. Ei-triviaalit vuokaaviot viittaavat sekavaan logiikkaan, jota tulisi välttää suurilla kustannuksilla.

Kommentit

• Vuokaaviot ovat myös loistava tapa s varmistaa, että jokainen päätöksentekokohta määrittelee toiminnot sekä harvinaisemmille että yleisimmille poluille. Tämä auttaa varmistamaan, että tiedät mitä tehdä, kun hyväksyntä evätään tai tilaus peruutetaan! Reunatapauksissa on usein enemmän vikoja, koska ihmiset unohtavat tehdä ne tai tekevät ne nopeasti laadunvalvonnan aikana testattaessa niitä.

Pseudokoodista

Ollakseni rehellinen, en käytä pseudokoodia paljon. Yleensä koodin kirjoittaminen on nopeampaa, jotta kun olen valmis minun koodi, se on todellinen koodi. Joissakin tapauksissa pseudokoodi voi olla hyödyllinen, mutta työskentelet yleensä jotain hyvin monimutkaista ja yrität vain hajottaa menetelmän tai jotain rakennetta. Näissä tapauksissa käytän IDE: n kommentteja rakenteen rakentamiseen. kunnes saan asiat oikein. Sitten menen sisään ja kirjoitan todellisen koodin kommentteihin. Tämä auttaa minua tekemään muutamia asioita:

• näen alueet, joita minulla ei ole ja joita luken kommentteja ja näen niissä ilmeisiä aukkoja.
• Kun täytän todellisen koodin, minulla on kommentteja, jotka selittävät englanniksi mitä teen. (He ”todennäköisesti tarvitsevat sitä, jos se on niin monimutkaista minun on ensin kirjoitettava pseudokoodi).

Vuokaavioissa

Koodi muuttuu tyypillisesti niin paljon, että vuokaavioista ei ole hyötyä lukuun ottamatta suurempaa, järjestelmän laajempaa arkkitehtuuria suunnittelu tai dokumentaatio. Tällöin ”vain taululle kaavion saadaksesi asioiden ydin tai näytettäväksi jollekin muulle tiimissä. Ellet todellakaan tarvitse vuokaaviota ymmärtämisen helpottamiseksi, sinun ei todellakaan tarvitse heitä” tekemään ”ohjelmistoja oikein. Nykyään on olemassa monia -laajennuksia IDE-laitteille , jotka tuottavat vuokaavioita itse koodista, luokkakaavioita ja muita (ja päinvastoin `). Ainoa reaaliaikainen aika, joka sinun ei tarvitse tehdä vakavasti tarkkaa vuokaaviota, on, jos et pysty pitämään koko arkkitehtuuria ja miten asiat toimivat kerralla ja sinun on puhuttava jotain visuaalista kiinni vääntymistä varten.

Yleensä en kirjoita vuokaavioita työskennellessäni henkilökohtaisten projektien parissa (koska projektit eivät ole kovin suuria) ja suurin osa panoksista, tuotoksista ja prosesseista on selkeitä.

mutta kun aloitat monimutkaisten suurten projektien, joissa on erilaiset tulolähteet, litteät tiedostot, tietokannat, manuaaliset rajapinnat jne. ovat hyödyllisiä. kirjoitat Pseudokoodia ja UML-digrameja, koska nämä työkalut auttavat sinua keksimään parempia luokkia, menetelmiä jne. Joskus kirjoittaessasi pseudokoodia löydät erilaisia ja tehokkaampia tapoja ratkaista ohjelma.

Pseudokoodi on tarkoitettu edustamaan idea nopeasti niille, jotka ymmärtävät ainakin koodin perusteet. Vuokaaviot ovat fr, jotka piirtävät kauniita kuvia kaikille muille ymmärtää samaa.

Vuokaavioita käytetään usein dokumentointitarkoituksiin, koska monet ihmiset käyttävät sitä, että dokumentaatio ja vuokaaviot ovat helpompia seuraa kuin näennäiskoodi muille kuin ohjelmoijille. Projektissa, jossa työskentelet itse, pseudokoodin kiinnittäminen on hienoa, koska se on paljon hyödyllisempi ja helpompi luoda, koska tarvitset vain tekstieditorin.

Vuokaaviot ovat korkea abstraktiotaso, joiden avulla voit suunnitella, miten asioiden tulisi edetä, esimerkiksi

jos x kuolee y voittaa

Niiden ei tarvitse riippua siitä, miten suunnittelet ohjelmaa luokkien ja menetelmien suhteen, toisaalta pseudokoodi anna alempi abstraktiotaso (vaikka se todella riippuu)

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

täten pseudokoodi voidaan nyt kääntää varsinaiseen ohjelmaan käyttämäsi kielen perusteella.

Pelille suosittelen ensin vuokaaviota ja sitten suunnittelua luokat ja menetelmät, kirjoita pseudokoodi ja muunna se lopuksi ohjelmaksi

Minä d ota huomioon kirjoittamasi koodin luonne. Jos se on:

1. erittäin iteratiivinen / rekursiivinen
2. haarat monimutkaisilla tavoilla
3. toteutettu useissa järjestelmissä, joita haluat edustaa

Kahdessa ensimmäisessä tapauksessa pseudokoodin lukeminen on asteittain vaikeampaa kuin ison kuvan kaavio. Toisaalta koodi, joka on enimmäkseen lineaarinen, tekee uskomattoman tylsistä kaavioista, jotka todella tekevät prosessista vaikeampaa ymmärtää, koska se räjäyttää sen.

Kolmannessa tapauksessa vuokaaviot edustavat paremmin prosesseja, jotka ylitä järjestelmän rajat ja edustavat koko prosessia.

1. Käytä mitä tahansa, mistä tunnet olosi mukavaksi. Minusta kuitenkin tuntuu, että vuokaavioita ei käytetä kovin paljon ohjelman ohjauksen luonnostamiseen nykyään; Ensinnäkin ne ovat tyypillisesti rakentamattomia, verrattuna pseudokoodiin. On yleisempää käyttää luokkariippuvuuskaavioita, kuten UML, kuvaamaan arkkitehtuuriasi paljon korkeammalla tasolla. Jos sovelluksessasi on tilakone, (vuokaavamaisen) tilakoneen kaavion piirtäminen on välttämätöntä.
2. Luulen, että olet oikeassa tässä. Yksi tapa toimia on kirjoittaa pseudokoodi kommentteina lähdetiedostoon aluksi ja lisätä todelliset toteutusrivit niiden joukkoon.
3. Käytä jälleen mitä tahansa, mistä tunnet olosi mukavaksi. Jos et ole varma, kokeile niitä molempia; uskon, että käytäntösi lähestyvät nopeasti mitä tahansa sinulle hyödyllisintä. Minusta henkilökohtaisesti ei ole vuokaavioita hyödyllistä, ellet yritä purkaa erityisen monimutkaista toteutusjärjestystä.

Miksi kirjoittaa pseudokoodia, kun voit kirjoittaa Java? Olen löytänyt Java, hyvän IDE: n ja Javadoc on helpoin tapa ymmärtää ohjelmointiongelma – ainakin olioihin suuntautunut . (Ja arcade-pelin pitäisi olla OO.) Kieli on suunniteltu alusta asti tätä varten. Sen yksinkertainen ja suoraviivainen. (Ehkä liian yksinkertainen moniin tarkoituksiin, mutta paras asia, jonka olen nähnyt tälle.) Javadocin hyperteksti ja IDE: n kautta itse koodi tekevät ymmärrettävämmän ”kaavion” kuin voit edes käyttää iso paperiarkki. Java-koodi on yhtä yksinkertainen kuin mikä tahansa pseudokoodi ja paljon tiukempi. Ja kun olet saanut sen ”kaaviomaisesti” ja ”pseudokoodattu”, ohjelma todella toimii!

Kommentit

• Java ja muut voivat olla pitkään käämittyjä. ” public static void main .. ” tai ” system.out.println ” tai pitkät tunnisteet, joissa on camelback-merkintä, kaarrettu sinne pitkään. n sitten poikkeukset, jotka on 2b kiinni..Ja minkä tahansa kirjastojen soittaminen voi olla pitkää. Muistan, että 10 vuotta sitten avasin tiedoston. jotain uutta BufferedReader (uusi InputStreamReader (System.in)); ilmeisesti helpompaa nyt mkyong.com / java / … Mutta oikeastaan mikä tahansa kirjasto, johon soitat, voi olla pitkäkestoinen, ei kuin pseudokoodi, joka voi olla niin ytimekäs kuin voit kuvitella
• myös java tai jokin muu kieli, osuma virheitä kokoamisessa. mikään pseudokoodilla. pääset keskittymään suunnitteluun ilman häiriötekijöitä. Kommentit pseudokoodista voivat olla paljon lyhyempiä, koska pseudokoodi on selvempi mielelle, kun se ’ on mielestä. ’ ei rajoitu ajattelemalla vain yhdellä kielellä, ja saatat nähdä ah i ’ käyttävän tätä muuta kieltä. ’ kirjoittaminen on nopeampaa ja vähemmän tuskallista (kokoelmia ei tarvita – jopa hyvin sujuvat kokoamisvirheet) ja niin vähän aikaa kirjoittamiseen helpottaa uudelleensuunnittelua.
• @barlop: Se toimii minulle, mutta se ei välttämättä toimi kaikille. Jätän paljon koodia (esimerkiksi ” BufferedReader ”) luokkistani, kunnes tarvitsen sitä tai minun on tiedettävä, voinko voi saada sen toimimaan. Silloinkin kun minulla on se, ’ istui hyvällä tavalla pois tieltä luokissa, joita minun ei ’ tarvitse tarkastella yleistä harkittaessa design. Kääntäjävirheet voidaan korjata helposti ja ne voivat estää suuria suunnitteluvirheitä, kuten väärän luokan käyttämisen kohdassa, jossa voit ’ edes saada esiintymän oikea luokka. Myönnän, että olen ” suunnitellut ” ohjelmiston tällä tavalla, joka voisi vain kirjoitetaan Java-kielellä, mutta OP käyttää Java-ohjelmaa.
• niin sanokaa, että haluat avata tiedoston, näetkö kuinka avoimen tiedoston pseudokoodi (” c: \ blah \ file ”) on lyhyempi kuin Java tehdä se? tai että tuloste ” dfdfd ” on lyhyempi kuin Java, jotta se voidaan tehdä? En ’ ole koskaan tehnyt (vielä) sivuja pseudokoodia ja useita luokkia. osittain ’ cos en ole ’ kirjoittanut isoja ohjelmia ikäisinä b) osittain ’ cos En luulisi ’ luulevan, luulen ’ d kirjoittavan jonkin pseudokoodin ja saan sen sitten toteutettua. Mikä tahansa muu pseudokoodi, jos sellaista on, olisi korkeampi. Minulla saattaa olla luettelo kaikista luokista ja menetelmistä, mukaan lukien rakentajat. Joten tiedän, mitkä luokat ovat ja mitä voin saada siitä.
• joten en olisi ’ en olisi tilanteessa, jossa käytän väärää luokkaa mutta joka tapauksessa, jos se ’ on ohjelmani, olen ’ d kirjoittanut muistiinpanoihini mikä luokka on mikä .. luokat ovat kauniita korkeatasoinen. Minulla ’ d on huomautus siitä, että jos voin ’ muistaa sen. Ja pseudokoodissa on kyse siitä, mitä kukin tarkoittaa, joten jos tarkoitit tehdä luokan blah-ilmentymän ja kirjoitit bleh, niin se ’ on vain kirjoitusvirhe, mutta se ei ole ’ t estä suunnittelua. (Jos ’ kirjoitat itse itsellesi ’ cos, tiedät mitä tarkoitat, ja käytit sitä kuin blah).

Voit käyttää vuokaaviota, jos olet hämmentynyt jos lausekkeet ja yrität ymmärtää että. Tai jos yrität ymmärtää silmukkaa, katso laskurien vaikutus. Jos opit siitä, se voi auttaa paljon.

Pseudokoodi on hyödyllinen ohjelman suunnittelussa. ilman häiriötä siitä, että syntaksin on oltava oikein, ja ilman pitkää tuulahdusta, jota joillakin kielillä voi olla. Se, että se on nopeampi kirjoittaa, helpottaa myös uudelleensuunnittelua koodi. Ja voit olla niin ytimekäs kuin mielesi haluaa, sen kirjoittaminen on miellyttävää, vaatii vähemmän henkistä vaivaa saadakseen sen toimimaan (ei virheenkorjausta tai paljon vähemmän) ja enemmän kykyä keskittyä kokonaisuuteen ja suunnitteluun.

Joten hyödyllinen itsellesi.

Niitä voidaan käyttää myös kommunikointiin muille.