Når vil jeg bruke pseudokode i stedet for flytskjema?

Fl owcharts og pseudocode har ofte samme nivå av uttrykksevne, men er forskjellige i linearisering. Pseudokode er lineær (dvs. en sekvens av linjer med instruksjoner), et flytskjema er ikke. Derfor er flytskjemaer et høyere abstraksjonsnivå, brukt før du skriver pseudokode eller til dokumentasjon.

Flytskjemaer har etter min mening to sterke fordeler i forhold til pseudokode: For det første er de grafiske. Mange ikke-tekniske mennesker har en sterk frykt for strukturert tekst, men ikke for grafiske beskrivelser, så flytskjemaer vil sitte mye bedre med dem. For det andre er flytskjemaer mye bedre til å uttrykke metahensyn som å vise hovedlinjen for utførelse i motsetning til grener.

Dine spørsmål i detalj:

1. For en virkelig komplisert problemet, vil du bruke flytskjemaer først, deretter pseudokode. Begge er valgfrie når du føler deg trygg nok.
2. Ja, pseudokode har fordelen av å være sammensmeltbar med ekte kode. Steve McConnell, for eksempel, anbefaler på det sterkeste skrivemetoder i pseudokode først og deretter la pseudokoden være i koden som kommentarer.
3. Jeg har alltid følt at behovet for å tegne et flytskjema under design viser utilstrekkelig deling av problemet ditt. Ikke-trivielle flytskjemaer indikerer kronglete logikk, som bør unngås til store kostnader.

Kommentarer

• Flytskjemaer er også gode måter å sørge for at hvert avgjørelsespunkt definerer handlingene for den mindre vanlige stien (e) så vel som den vanligste. Dette bidrar til at du vet hva du skal gjøre når godkjenningen nektes eller bestillingen blir kansellert! Det er ofte flere feil i kant tilfellene fordi folk glemmer å gjøre dem eller gjøre det i et rush i løpet av QA når testing finner dem.

På Pseudo-kode

For å være ærlig bruker jeg ikke pseudokode mye. Vanligvis er det raskere å bare skrive koden, slik at når jeg er ferdig med koden min, den er den faktiske koden. Det er noen tilfeller når pseudokode kan være nyttig, men du jobber generelt med noe veldig komplisert og prøver bare å bryte ned strukturen til en metode eller noe. I slike tilfeller bruker jeg kommentarer i IDE-en min for å legge opp strukturen til jeg får ting riktig. Deretter går jeg inn og skriver selve koden i kommentarene. Dette hjelper meg å gjøre noen få ting:

• Jeg kan se områder jeg har og ikke har implementert av lese kommentarene og se tydelige hull i dem.
• Når jeg fyller ut den virkelige koden, har jeg kommentarer som forklarer på engelsk hva jeg gjør. (De vil sannsynligvis trenge det hvis det er så komplisert. at jeg trenger å skrive pseudokode først. design eller dokumentasjon. I de tilfellene vil jeg bare skrive et diagram for å få kjernen i ting eller vise til noen andre på teamet. Med mindre du virkelig trenger et flytskjema for å hjelpe deg med å forstå, trenger du ikke dem for å «gjøre» programvare Ikke sant. I dag er det mange plugins for IDEs som vil generere flytskjemaer fra selve koden, i tillegg til klassediagrammer og andre (og omvendt `). Den eneste sanne tiden du trenger for å gjøre et seriøst nøyaktig flytskjema, er hvis du ikke kan beholde hele arkitekturen og hvordan ting fungerer i hodet på en gang og trenger å snakke gjennom noe visuelt for å fange kinks.

Generelt skriver jeg ikke flytskjemaer mens jeg jobber med personlige prosjekter (da prosjekter ikke er mye store) og de fleste inngangene, utgangene og prosessene er klare.

men da du begynner å jobbe med komplekse store prosjekter med forskjellige inngangskilder, er flate filer, databaser, manuelle grensesnitt osv. flytdiagrammer nyttige.

Jeg vil anbefale du skriver Pseudo-kode og UML-digrammer, ettersom disse verktøyene vil hjelpe deg med å finne bedre klasser, metoder osv. Noen ganger mens du skriver pseudokode, vil du finne forskjellige og mer effektive måter å løse et program på.

Pseudokode er for å raskt representere en idé for de som forstår i det minste det grunnleggende om koden. Flytskjemaer er fra å tegne pene bilder for alle andre å forstå det samme.

Flytskjema brukes ofte til dokumentasjonsformål fordi mange forskjellige mennesker bruker dokumentasjon og flytskjemaer er lettere å følge enn pseudokode for ikke-programmerere. I et prosjekt du jobber med for deg selv, er det greit å holde fast ved pseudokode, det er mye mer nyttig og mye lettere å lage, siden en tekstredigerer er alt du trenger.

Flytskjemaer er et høyt abstraksjonsnivå, de lar deg planlegge hvordan ting skal gå, for eksempel

hvis x dies y wins

De trenger ikke å avhenge av hvordan du designer programmet når det gjelder klasser og metoder, pseudokode derimot gi et lavere abstraksjonsnivå (selv om det virkelig avhenger)

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

Dermed kan pseudokode nå oversettes til faktisk program basert på språket du bruker.

For et spill vil jeg anbefale å bruke et flytskjema først, deretter utforme klassene og metodene, skriv pseudokode og konverter det til slutt til et program

Jeg ville d vurdere arten av koden du skriver. Hvis det er:

1. Svært iterativ / rekursiv
2. Filialer på kompliserte måter
3. Implementert i flere systemer, som du vil representere

I de to første tilfellene blir pseudokode gradvis vanskeligere å lese enn et stort bildediagram. På den annen side gir kode som hovedsakelig er lineær utrolig kjedelige diagrammer som faktisk gjør prosessen vanskeligere å forstå på grunn av hvor mye den sprenger den.

For det tredje tilfellet er flytskjemaer bedre til å representere prosesser som krysse systemgrensene og representer hele prosessen.

1. Du bør bruke det du føler deg komfortabel med. Når det er sagt, er mitt inntrykk at flytskjemaer ikke brukes mye for å skissere programkontroll i disse dager; for det første er de vanligvis ustrukturerte, sammenlignet med pseudokode. Det er mer vanlig å bruke klasseavhengighetsdiagrammer som UML, for å beskrive arkitekturen på et mye høyere nivå. Hvis applikasjonen din har en tilstandsmaskin, er det også viktig å tegne et (flytskjema-lignende) tilstandsmaskinediagram.
2. Jeg tror du har rett her. En måte å jobbe på er å skrive ut pseudokoden din som kommentarer i kildefilen din til å begynne med, og sette inn de faktiske implementeringslinjene blant dem.
3. Igjen, bruk det du føler deg komfortabel med. Hvis du ikke er sikker, kan du prøve dem begge. Jeg forventer at din praksis raskt vil samles om hva som er mest nyttig for deg. Jeg synes personlig ikke at flytskjemaer er nyttige, med mindre jeg prøver å løse en spesielt komplisert utførelsesordre.

Hvorfor skrive pseudokode når du kan skrive Java? Jeg har funnet Java, en god IDE, og Javadoc er den enkleste måten å forstå et programmeringsproblem – i det minste en Objektorientert . (Og et arkadespill burde være OO.) Språket ble designet fra grunnen av for dette. Det er enkelt og greit. (For enkelt for mange formål, kanskje, men det beste jeg har sett for dette.) Hyperteksten i Javadoc og, via en IDE, i selve koden gir et mer forståelig «diagram» enn du kunne tegne på selv et stort ark. Java-kode er like enkel som hvilken som helst pseudokode og en god del strengere. Og når du først har fått den «diagrammert» og «pseudo» -kodet, vil programmet faktisk kjøre!

Kommentarer

• java og andre kan være langvarige. » offentlig statisk ugyldig hoved .. » eller » system.out.println » eller lange identifikatorer med camelback-notasjon, langvarig der.n da unntak at har 2b fanget..Og å ringe biblioteker kan være langvarig. Jeg husker at jeg for 10 år siden åpnet en fil. noe sånt som ny BufferedReader (ny InputStreamReader (System.in)); tilsynelatende lettere nå mkyong.com / java / … Men egentlig kan ethvert bibliotek du ringer være langvarig, ikke som pseudokode som kan være så kortfattet som du kan forestille deg
• også i java eller hvilket som helst språk, du treffer feil på kompilering. ingenting av det med pseudokode. du får fokusere på design uten distraksjon. Kommentarer til pseudokode kan være mye mer korte ettersom pseudokode er klarere for sinnet da den ‘ er fra sinnet. Du ‘ er ikke begrenset av å tenke på bare ett språk, og du kan se ah i ‘ vil du bruke dette andre språket. Det ‘ er raskere og mindre smertefullt å skrive (ingen kompilasjoner er nødvendige – selv de veldig flytende får kompileringsfeil) og så mindre tid til å skrive gjør det lettere å redesigne.
• @barlop: Det fungerer for meg, men det fungerer kanskje ikke for alle. Jeg lar mye kode (» BufferedReader «, for eksempel) ut av klassene mine til jeg trenger det eller trenger å vite om jeg kan få det til å fungere. Selv når jeg har det, er det ‘ stashed pent ut av veien i klasser jeg ikke trenger ‘ når jeg vurderer samlet design. Kompilatorfeil løses enkelt og kan forhindre store designfeil, for eksempel å bruke feil klasse på et punkt der du kan ‘ til og med få en forekomst av riktig klasse. Jeg innrømmer at jeg har » designet » programvare på denne måten som bare kunne skrives på Java, men OP bruker Java.
• så si at du vil åpne en fil, ser du hvordan pseudokode for openfile (» c: \ blah \ file «) er kortere enn java for å gjøre det? eller at utskriften » dfdfd » er kortere enn java for å gjøre det? Jeg har ‘ aldri (ennå) gjort sider med pseudokode og flere klasser. delvis ‘ cos Jeg har ikke ‘ t skrev store programmer i aldre b) delvis ‘ cos Jeg tror ikke ‘ jeg vil, jeg tror jeg ‘ d skriver litt pseudokode og får den implementert. Enhver annen pseudokode, hvis det er noen, vil være høyere nivå. Jeg har kanskje en liste over alle klasser og metoder, inkludert konstruktører. Så jeg vet hvilke klasser som er hva og at jeg kan få en forekomst av det ..
• så jeg ville ikke ‘ ikke være i en situasjon med å bruke feil klasse men uansett, hvis det ‘ er programmet mitt, har jeg ‘ d skrevet ned i notatene mine hvilken klasse er hva .. klassene er fine høy level. jeg ‘ d har en merknad om at hvis jeg ikke kan ‘ ikke huske det. Og pseudokode handler om hva man mener, så hvis du mente å lage en forekomst av klasse bla og du skrev bleh, så er det ‘ bare en skrivefeil, men det ‘ t hindrer designet ditt. (hvis du ‘ skriver for deg selv ‘ fordi du vet hva du mener, og du brukte det som en bla).

Du kan bruke et flytskjema hvis du blir veldig forvirret av hvis uttalelser og du prøver å forstå at. Eller hvis du prøver å forstå en løkke, kan du se effekten av tellere. Hvis du lærer det, kan det hjelpe mye.

Det kan føles litt begrensende «for du må legge korte utsagn i bokser. Og hvis programmet ditt er veldig lineært og sløyfene dine og hvis det er trivielt, så ser jeg ingen nytte for det. >

Pseudokode er nyttig for å designe et program uten distrahering av å måtte få syntaksen riktig, og uten langvarighet som noen språk kan innebære. Det at det er raskere å skrive gjør det også lettere å redesigne kode. Og du kan være så kortfattet som tankene dine ønsker, det er hyggelig å skrive, krever mindre mental innsats for å få det til å fungere (som ingen eller mye mindre feilsøking), og mer evne til å fokusere på det store bildet og designet.

Så nyttig for deg selv.

De kan også brukes til å kommunisere med andre.