När skulle jag använda pseudokod istället för flödesschema?

Fl owcharts och pseudokod har ofta samma uttrycksnivå, men skiljer sig åt i linjärisering. Pseudokod är linjär (dvs. en sekvens av rader med instruktioner), ett flödesschema är inte. Därför är flödesscheman en högre abstraktionsnivå, som används innan du skriver pseudokod eller för dokumentation.

Flödesscheman har enligt min mening två starka fördelar jämfört med pseudokod: För det första är de grafiska. Många icke-tekniska personer har en stark rädsla för strukturerad text, men inte för grafiska beskrivningar, så flödesscheman kommer att sitta mycket trevligare med dem. För det andra är flödesscheman mycket bättre på att uttrycka metaöverväganden som att visa huvudlinjen för körning i motsats till grenar.

Dina frågor i detalj:

1. För en riktigt komplicerad problem, skulle du använda flödesscheman först och sedan pseudokod. Båda är valfria när du känner dig tillräckligt säker.
2. Ja, pseudokod har fördelen att den går att smälta med riktig kod. Steve McConnell rekommenderar till exempel starkt att skriva metoder i pseudokod först och sedan lämna pseudokoden i koden som kommentarer.
3. Jag kände alltid att behovet av att rita ett flödesschema under designen visar otillräcklig delning av ditt problem. Icke-triviala flödesscheman indikerar inblandad logik, vilket bör undvikas till stora kostnader.

Kommentarer

• Flödesscheman är också bra sätt för att se till att varje beslutsställe definierar åtgärder för den mindre vanliga vägen eller de vanligaste. Detta hjälper till att se till att du vet vad du ska göra när godkännandet nekas eller beställningen annulleras! Det finns ofta fler buggar i edge-fallen eftersom människor glömmer att göra dem eller göra det i en rusning under QA när testet hittar dem.

På Pseudokod

För att vara ärlig använder jag inte pseudokod mycket. Vanligtvis är det snabbare att bara skriva koden, så att när jag är klar med min kod, den är den faktiska koden. Det finns vissa fall där pseudokod kan vara till hjälp, men du jobbar generellt med något mycket komplext och bara försöker bryta ner strukturen för en metod eller något. I sådana fall använder jag kommentarer i min IDE för att lägga upp strukturen tills jag får rätt på saker. Sedan går jag in och skriver den faktiska koden i kommentarerna. Detta hjälper mig att göra några saker:

• Jag kan se områden jag har och inte har implementerat av läser kommentarerna och ser uppenbara luckor i dem.
• När jag fyller i den riktiga koden har jag kommentarer som förklarar på engelska vad jag gör. (De kommer förmodligen behöva det om det är så komplicerat att jag måste skriva pseudokod först).

På flödesscheman

Koden ändras vanligtvis så mycket att flödesscheman inte är till hjälp förutom större, mer systemomfattande arkitektur design eller dokumentation. I dessa fall kommer jag bara att skriva ett diagram för att få kärnan i saker eller visa för någon annan i teamet. Om du inte verkligen behöver ett flödesschema för att hjälpa dig att förstå, behöver du inte verkligen dem för att ”göra” programvara rätt. Numera finns det många plugins för IDEs som genererar flödesscheman från själva koden, liksom klassdiagram och andra (och vice versa `). Den enda realtid du behöver göra ett seriöst noggrant flödesschema är om du inte kan behålla hela arkitekturen och hur saker fungerar i ditt huvud på en gång och behöver prata igenom något visuellt för att fånga knep.

Generellt skriver jag inte flödesscheman medan jag arbetar med personliga projekt (eftersom projekt inte är så stora) och de flesta ingångar, utgångar och processer är tydliga.

men eftersom du kommer att börja arbeta med komplexa stora projekt med olika ingångskällor är platta filer, databaser, manuella gränssnitt etc. flödesscheman praktiska.

Jag skulle rekommendera du skriver Pseudo-kod och UML-digram eftersom dessa verktyg hjälper dig att komma med bättre klasser, metoder etc. Ibland kommer du att hitta olika och effektivare sätt att lösa ett program medan du skriver pseudokod.

Pseudokod är för att snabbt representera en idé för dem som förstår åtminstone grunderna i kod. Flödesscheman är fr att rita vackra bilder för alla andra för att förstå samma sak.

Flödesscheman används ofta i dokumentationssyfte eftersom många olika människor använder den dokumentationen och flödesscheman är lättare att följa än pseudokod för icke-programmerare. I ett projekt som du själv arbetar med att hålla fast vid pseudokod är bra eftersom det är mycket mer användbart och mycket lättare att skapa eftersom en textredigerare är allt du behöver.

Flödesscheman är en hög abstraktionsnivå de låter dig planera hur saker ska gå, till exempel

om x dies y wins

De behöver inte bero på hur du utformar programmet när det gäller klasser och metoder, pseudokod å andra sidan ge en lägre abstraktionsnivå (även om det verkligen beror på det)

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

pseudokod kan alltså nu översättas till det faktiska programmet baserat på det språk du använder.

För ett spel rekommenderar jag att du använder ett flödesschema först och sedan designar klasserna och metoderna, skriv pseudokod och slutligen konvertera den till ett program

Jag vill d överväga karaktären på koden du skriver. Om det är:

1. Mycket iterativ / rekursiv
2. Filialer på komplicerade sätt
3. Implementerade i flera system som du vill representera

I de första två fallen blir pseudokod gradvis svårare att läsa än ett stort bilddiagram. Å andra sidan gör kod som mestadels är linjär otroligt tråkiga diagram som faktiskt gör processen svårare att förstå på grund av hur mycket den spränger den.

För det tredje fallet är flödesscheman bättre att representera processer som överskrider systemgränser och representerar hela processen.

1. Du bör använda vad du känner dig bekväm med. Med detta sagt är mitt intryck att flödesscheman inte används mycket för att skissera programkontrollen i dessa dagar; för det första är de vanligtvis ostrukturerade jämfört med pseudokod. Det är vanligare att använda klassberoende diagram som UML för att beskriva din arkitektur på en mycket högre nivå. Om din applikation har en tillståndsmaskin är det också viktigt att rita ett (flödesschema-liknande) tillståndsdiagram.
2. Jag tror att du har rätt här. Ett sätt att arbeta är att skriva ut din pseudokod som kommentarer i din källfil till att börja med och infoga de verkliga implementeringsraderna bland dem.
3. Återigen, använd vad du känner dig bekväm med. Om du är osäker, prova dem båda. Jag förväntar mig att din övning snabbt kommer att konvergera vad som är mest användbart för dig. Jag tycker personligen att flödesscheman inte är användbara om jag inte försöker lösa upp en särskilt komplicerad körningsordning.

Varför skriva pseudokod när du kan skriva Java? Jag har hittat Java, en bra IDE och Javadoc är det enklaste sättet att förstå ett programmeringsproblem – åtminstone ett objektorienterat . (Och ett arkadspel borde vara OO.) Språket designades från grunden för detta. Det är enkelt och enkelt. (För enkelt för många ändamål, kanske, men det bästa jag har sett för detta.) Hypertexten i Javadoc och, via en IDE, i själva koden ger ett mer förståeligt ”diagram” än du kan rita på till och med ett stort ark papper. Java-kod är lika enkel som vilken pseudokod som helst och mycket mer rigorös. Och när du väl har fått den ”schematiserad” och ”pseudo” -kodad kommer programmet faktiskt att köras!

Kommentarer

• java och andra kan vara långvariga. ” offentliga statiska ogiltiga main .. ” eller ” system.out.println ” eller långa identifierare med camelback-notering, långvarig där.n sedan undantag att har 2b fångat..Och att ringa alla bibliotek kan vara långa. Jag kommer ihåg att jag för 10 år sedan öppnade en fil. något som ny BufferedReader (ny InputStreamReader (System.in)); tydligen lättare nu mkyong.com / java / … Men egentligen kan alla bibliotek du ringer vara långa, inte som pseudokod som kan vara så kortfattad som du kan föreställa dig
• även i java eller vilket språk som helst, du träffar på fel vid sammanställning. inget av det med pseudokod. du får fokusera på design utan distraktion. Kommentarer om pseudokod kan vara mycket kortare eftersom pseudokod är tydligare för sinnet eftersom den ’ är från sinnet. Du ’ begränsas inte av att du bara tänker på ett språk och du kanske ser ah i ’ kommer att använda det andra språket. Det ’ är snabbare och mindre smärtsamt att skriva (inga samlingar behövs – även de mycket flytande får kompileringsfel) och så kortare tid att skriva gör det lättare att omforma.
• @barlop: Det fungerar för mig, men det kanske inte fungerar för alla. Jag lämnar en hel del kod (” BufferedReader ”, till exempel) från mina klasser tills jag behöver det eller behöver veta om jag kan få det att fungera. Även när jag har det stavas det ’ snyggt ur vägen i klasser som jag inte behöver ’ tänker på när jag överväger övergripande design. Kompilatorfel fixas enkelt och kan förhindra stora designfel, som att använda fel klass vid en punkt där du ’ inte ens kan få en instans av rätt klass. Jag erkänner att jag har ” utformat ” programvara på det här sättet som bara kunde skrivas i Java, men OP använder Java.
• så säg att du vill öppna en fil, ser du hur pseudokod för openfile (” c: \ blah \ file ”) är kortare än java för att göra det? eller att utskriften ” dfdfd ” är kortare än Java för att göra det? Jag ’ har aldrig gjort (ännu) sidor med pseudokod och flera klasser. delvis ’ cos jag har inte ’ t skrivna stora program i åldrarna b) delvis ’ cos Jag tror inte ’, jag tror att jag ’ skulle skriva lite pseudokod och sedan få det implementerat. Varje annan pseudokod om den finns, skulle vara högre. Jag kanske har en lista över alla klasser och metoder inklusive konstruktörer. Så jag vet vilka klasser som är vad och att jag kan få en instans av det ..
• så jag skulle inte ’ inte vara i en situation med att använda fel klass men hur som helst, om det ’ är mitt program, så har jag ’ skrivit ner i mina anteckningar vilken klass som är vad .. klasserna är vackra hög nivå. jag ’ har en anteckning om att om jag inte kan ’ t kommer ihåg det. Och pseudokod handlar om vad man menar, så om du menade att göra en förekomst av klass bla och du skrev bleh, så är det ’ bara ett skrivfel men det ’ t hindra din design. (om du ’ skriver för dig själv ’ för du vet vad du menar och du använde det som en bla).

Du kan använda ett flödesschema om du blir riktigt förvirrad av om uttalanden och du försöker förstå det där. Eller om du försöker förstå en slinga, se effekten av räknare. Om du lär dig kan det hjälpa mycket.

Det kan kännas lite begränsande ”för att du måste lägga korta uttalanden i rutor. Och om ditt program är väldigt linjärt och dina loopar och ifs är triviala, ser jag ingen nytta för det.

Pseudokod är användbar för att designa ett program utan att distrahera att behöva få syntaxen rätt, och utan den långvarighet som vissa språk kan innebära. Det att det är snabbare att skriva gör det också lättare att omforma koda. Och du kan vara så kortfattad som ditt sinne önskar, det är trevligt att skriva, kräver mindre mentala ansträngningar för att få det att fungera (som ingen eller mycket mindre felsökning) och mer förmåga att fokusera på helheten och designen.

Så bra för dig själv.

De kan också användas för att kommunicera med andra.