Hvornår vil jeg bruge pseudokode i stedet for rutediagram?

Fl owcharts og pseudocode har ofte det samme niveau af ekspressivitet, men er forskellige i linearisering. Pseudokode er lineær (dvs. en række af linjer med instruktioner), et rutediagram er det ikke. Derfor er flowcharts et højere abstraktionsniveau, der bruges inden du skriver pseudocode eller til dokumentation.

Flowcharts har efter min mening to stærke fordele i forhold til pseudocode: For det første er de grafiske. Mange ikke-tekniske mennesker har en stærk frygt for struktureret tekst, men ikke for grafiske beskrivelser, så flowcharts vil sidde meget pænere med dem. For det andet er flowcharts meget bedre til at udtrykke metaovervejelser som at vise hovedlinjen for udførelse i modsætning til grene.

Dine spørgsmål i detaljer:

1. For en virkelig kompliceret problem, bruger du først flowcharts og derefter pseudokode. Begge er valgfri, når du føler dig sikker nok.
2. Ja, pseudokode har den fordel, at den kan flettes sammen med ægte kode. Steve McConnell anbefaler for eksempel kraftigt skrivemetoder i pseudocode først og derefter lade pseudocode være i koden som kommentarer.
3. Jeg har altid følt, at behovet for at tegne et flowchart under design viser utilstrækkelig deling af dit problem. Ikke-trivielle rutediagrammer indikerer indviklet logik, som skal undgås til store omkostninger.

Kommentarer

• Flowdiagrammer er også en god måde at for at sikre, at hvert beslutningspunkt definerer handlinger for den mindre almindelige sti såvel som den mest almindelige. Dette hjælper med at sikre, at du ved, hvad du skal gøre, når godkendelsen nægtes, eller ordren annulleres! Der er ofte flere bugs i kanttilfælde, fordi folk glemmer at gøre dem eller gøre det i en fart under QA, når test finder dem.

På Pseudo-kode

For at være ærlig bruger jeg ikke pseudokode meget. Typisk er det hurtigere at bare skrive koden, så når jeg er færdig med min kode, den er den faktiske kode. Der er nogle tilfælde, hvor pseudokode kan være nyttigt, men du arbejder generelt på noget meget komplekst og prøver bare at nedbryde strukturen i en metode eller noget. I disse tilfælde bruger jeg kommentarer i min IDE til at lægge strukturen ud indtil jeg får tingene rigtige. Derefter går jeg ind og skriver den faktiske kode i kommentarerne. Dette hjælper mig med at gøre et par ting:

• Jeg kan se områder, jeg har og ikke har implementeret af læser kommentarerne og ser tydelige huller i dem.
• Når jeg udfylder den rigtige kode, har jeg kommentarer, der forklarer på engelsk, hvad jeg laver. (De har sandsynligvis brug for det, hvis det er så kompliceret at jeg først skal skrive pseudokode).

På flowcharts

Koden ændres typisk så meget, at flowcharts ikke er nyttige, bortset fra større, mere systemomspændende arkitektur design eller dokumentation. I disse tilfælde vil jeg bare skrive et diagram på et diagram for at få kendskab til tingene eller for at vise en anden på holdet. Medmindre du virkelig har brug for et rutediagram for at hjælpe dig med at forstå, så behøver du ikke rigtig dem til at “gøre” software ret. I dag er der masser af plugins til IDEer , der genererer flowcharts fra selve koden samt klassediagrammer og andre (og omvendt `). Den eneste rigtige tid, du har brug for til at lave et seriøst nøjagtigt rutediagram, er hvis du ikke kan beholde hele arkitekturen, og hvordan tingene fungerer i dit hoved på én gang og har brug for at tale igennem noget visuelt for at fange kinks.

Generelt skriver jeg ikke flowcharts, mens jeg arbejder på personlige projekter (da projekter ikke er meget store) og de fleste af input, output og processer er klare.

men da du begynder at arbejde på komplekse store projekter med forskellige inputkilder, er flade filer, databaser, manuelle grænseflader osv. flowcharts praktisk.

Jeg vil anbefale du skriver Pseudo-kode og UML-digrammer, da disse værktøjer hjælper dig med at komme med bedre klasser, metoder osv. Nogle gange, mens du skriver pseudokode, finder du forskellige og mere effektive måder at løse et program på.

Pseudokode er til hurtigt at repræsentere en idé for dem, der i det mindste forstår det grundlæggende i kode. Flowcharts er fr tegner smukke billeder til alle andre at forstå det samme.

Flowdiagrammer bruges ofte til dokumentationsformål, fordi mange forskellige mennesker bruger den dokumentation og flowcharts er lettere at følg end pseudokode for ikke-programmører. I et projekt, du arbejder på for dig selv, er det fint med pseudokode, da det er meget mere nyttigt og meget lettere at oprette, da en teksteditor er alt, hvad du har brug for.

Flowcharts er et højt abstraktionsniveau, de giver dig mulighed for at planlægge, hvordan ting skal fortsætte, for eksempel

hvis x dies y vinder

De behøver ikke afhænge af, hvordan du designer programmet med hensyn til klasser og metoder, pseudokode på den anden side give et lavere abstraktionsniveau (selvom det virkelig afhænger)

hvis (isdead (s)) y.win ()

således kan pseudokode nu oversættes til det faktiske program baseret på det sprog, du bruger.

For et spil vil jeg anbefale at bruge et flowchart først og derefter designe klasser og metoder, skriv pseudokode og konverter det til et program

Jeg ville d overveje arten af den kode, du skriver. Hvis det er:

1. Meget iterativ / rekursiv
2. Filialer på komplicerede måder
3. Implementeret i flere systemer, som du vil repræsentere

I de to første tilfælde bliver pseudokode gradvis sværere at læse end et stort billeddiagram. På den anden side gør kode, der for det meste er lineær, utroligt kedelige diagrammer, der faktisk gør processen sværere at forstå på grund af hvor meget den sprænger den op.

For det tredje tilfælde er flowcharts bedre til at repræsentere processer, der krydser systemgrænser og repræsenterer hele processen.

1. Du skal bruge alt, hvad du har det godt med. Når det er sagt, er mit indtryk, at flowcharts ikke er meget brugt til at skitsere programstyring i disse dage; for det første er de typisk ustrukturerede sammenlignet med pseudokode. Det er mere almindeligt at bruge klasseafhængighedsdiagrammer som UML til at beskrive din arkitektur på et meget højere niveau. Også, hvis din applikation har en tilstandsmaskine, er det vigtigt at tegne et (flowchart-lignende) tilstandsmaskindiagram.
2. Jeg synes, du har ret her. En måde at arbejde på er at skrive din pseudokode ud som kommentarer i din kildefil til at begynde med og indsætte de faktiske implementeringslinjer blandt dem.
3. Igen, brug hvad du har det godt med. Hvis du ikke er sikker, så prøv dem begge; jeg forventer, at din praksis hurtigt vil komme sammen om hvad der er mest nyttigt for dig. Jeg finder personligt ikke flowcharts nyttige, medmindre jeg prøver at løse en særlig kompliceret eksekveringsordre.

Hvorfor skrive pseudokode, når du kan skrive Java? Jeg har fundet Java, en god IDE, og Javadoc er den nemmeste måde at forstå et programmeringsproblem på – i det mindste en Objektorienteret . (Og et arkadespil burde være OO.) Sproget blev designet fra bunden til dette. Det er simpelt og ligetil. (Måske for simpelt til mange formål, men det bedste, jeg har set til dette.) Hyperteksten i Javadoc og via en IDE i selve koden giver et mere forståeligt “diagram”, end du kunne trække på selv et stort ark papir. Java-kode er så enkel som enhver pseudokode og en hel del mere stringent. Og når du først har fået den “diagrammeret” og “pseudo” kodet, kører programmet faktisk!

Kommentarer

• java og andre kan være langvarige. ” offentlig statisk ugyldig main .. ” eller ” system.out.println ” eller lange identifikatorer med camelback-notation, langvarig der.n derefter undtagelser, der har 2b fanget..Og at kalde på ethvert bibliotek kan være langvarig. Jeg husker for 10 år siden at have åbnet en fil. noget som nyt BufferedReader (nyt InputStreamReader (System.in)); tilsyneladende lettere nu mkyong.com / java / … Men virkelig ethvert bibliotek, du kalder, kan være langvarig, ikke som pseudokode, som kan være så kortfattet som du kan forestille dig
• også i java eller ethvert sprog, du rammer fejl ved kompilering. intet af det med pseudokode. du får fokus på design uden distraktion. Kommentarer til pseudocode kan være meget mere korte, da pseudocode er klarere for sindet, da den ‘ er fra sindet. Du ‘ er ikke begrænset af kun at tænke på et sprog, og du kan muligvis se ah i ‘ vil jeg bruge dette andet sprog. Det ‘ er hurtigere og mindre smertefuldt at skrive (ingen kompileringer er nødvendige – selv de meget flydende får kompileringsfejl) og så mindre tid til at skrive gør det lettere at redesigne.
• @barlop: Det virker for mig, men det fungerer muligvis ikke for alle. Jeg efterlader en masse kode (” BufferedReader ” for eksempel) uden for mine klasser, indtil jeg har brug for det eller har brug for at vide, om jeg kan få det til at fungere. Selv når jeg har det, er det ‘ skjult pænt ud af vejen i klasser, jeg behøver ikke ‘ at se på, når jeg overvejer samlet design. Compilerfejl løses let og kan forhindre større designfejl, f.eks. Ved at bruge den forkerte klasse på et punkt, hvor du ‘ ikke engang kan få en forekomst af rigtige klasse. Jeg indrømmer, at jeg har ” designet ” software på denne måde, der kun kunne skrives på Java, men OP bruger Java.
• så sig, at du vil åbne en fil, kan du se, hvordan pseudokode for openfile (” c: \ blah \ file “) er kortere end java for at gøre det? eller at udskriften ” dfdfd ” er kortere end java for at gøre det? Jeg ‘ har aldrig gjort (endnu) sider med pseudokode og flere klasser. delvist ‘ cos Jeg har ikke ‘ t skrev store programmer i alderen b) delvis ‘ cos Jeg tror ikke ‘ jeg ville, jeg tror jeg ‘ skriver en pseudokode og får den implementeret. Enhver anden pseudokode, hvis der er nogen, ville være højere niveau. Jeg har muligvis en liste over alle klasser og metoder inklusive konstruktører. Så jeg ved, hvilke klasser der er, og at jeg kan få en forekomst af det ..
• så jeg ville ikke ‘ ikke være i en situation med at bruge den forkerte klasse men alligevel, hvis det ‘ er mit program, har jeg ‘ d skrevet ned i mine noter, hvilken klasse er hvad .. klasser er smukke højt niveau. jeg ‘ har en note om, at hvis jeg ikke kan ‘ ikke huske det. Og pseudokode handler alt om hvad man mener, så hvis du mente at lave en forekomst af klasse bla og du skrev bleh, så er det ‘ bare en skrivefejl, men det betyder ikke ‘ t forhindrer dit design. (hvis du ‘ skriver for dig selv ‘ fordi du ved hvad du mener, og du brugte det som en bla).

Du kan bruge et rutediagram, hvis du bliver rigtig forvirret af hvis udsagn, og du prøver at forstå at. Eller hvis du prøver at forstå en sløjfe, kan du se effekten af tællere. Hvis du lærer, kan det hjælpe meget.

Det kan føles lidt restriktivt “for du skal sætte korte udsagn i kasser. Og hvis dit program er meget lineært, og dine sløjfer og hvis er trivielle, så ser jeg ingen brug for det.

Pseudokode er nyttig til at designe et program uden distraktion for at skulle få syntaksen til rette og uden den langvarighed, som nogle sprog kan indebære. Det faktum, at det er hurtigere at skrive, gør det også lettere at redesigne kode. Og du kan være så kortfattet som dit sind ønsker, det er behageligt at skrive, kræver mindre mental indsats for at få det til at arbejde (som ingen eller meget mindre debugging) og mere evne til at fokusere på det store billede og design.

Så nyttigt for dig selv.

De kan også bruges til at kommunikere med andre.