Wanneer zou ik pseudocode gebruiken in plaats van stroomdiagrammen?

Fl owcharts en pseudocode hebben vaak dezelfde expressiviteit, maar verschillen in linearisering. Pseudocode is lineair (d.w.z. een reeks regels met instructies), een stroomschema is dat niet. Daarom zijn stroomdiagrammen een hoger abstractieniveau en worden ze gebruikt voordat pseudocode wordt geschreven of voor documentatie.

Stroomdiagrammen hebben naar mijn mening twee sterke voordelen ten opzichte van pseudocode: Ten eerste zijn ze grafisch. Veel niet-technische mensen hebben een sterke angst voor gestructureerde tekst, maar niet voor grafische beschrijvingen, dus stroomdiagrammen passen er veel beter bij. Ten tweede zijn stroomdiagrammen veel beter in het uitdrukken van meta-overwegingen, zoals het tonen van de hoofdlijn van uitvoering, in tegenstelling tot branches.

Uw vragen in detail:

1. Voor een echt gecompliceerde probleem, zou u eerst stroomdiagrammen gebruiken en daarna pseudocode. Beide zijn optioneel als je je veilig genoeg voelt.
2. Ja, pseudocode heeft het voordeel dat het kan worden samengevoegd met echte code. Steve McConnell raadt bijvoorbeeld sterk aan om methoden eerst in pseudocode te schrijven en dan de pseudocode in de code als commentaar achter te laten.
3. Ik heb altijd het gevoel gehad dat de noodzaak om een stroomdiagram te tekenen tijdens het ontwerpen onvoldoende partitie van je probleem laat zien. Niet-triviale stroomdiagrammen geven ingewikkelde logica aan, die tegen hoge kosten moet worden vermeden.

Opmerkingen

• Stroomdiagrammen zijn ook geweldige manieren om om ervoor te zorgen dat elk beslissingspunt de acties definieert voor zowel de minder gebruikelijke pad (en) als de meest voorkomende. Dit zorgt ervoor dat u weet wat u moet doen als de goedkeuring wordt geweigerd of de bestelling wordt geannuleerd! Er zijn vaak meer bugs in de randgevallen omdat mensen ze vergeten te doen of ze haastig doen tijdens QA wanneer ze worden gevonden door testen.

Op pseudocode

Om eerlijk te zijn, gebruik ik pseudocode niet veel. Meestal is het sneller om gewoon de code te schrijven, zodat als ik klaar ben met mijn code, het is echte code. Er zijn gevallen waarin pseudocode nuttig kan zijn, maar je werkt over het algemeen aan iets heel ingewikkelds en je probeert gewoon de structuur van een methode of zoiets af te breken. In die gevallen gebruik ik opmerkingen in mijn IDE om de structuur op te maken totdat ik alles goed heb. Dan ga ik naar binnen en schrijf de eigenlijke code in de opmerkingen. Dit helpt me een paar dingen te doen:

• Ik kan gebieden zien die ik heb en die ik niet heb geïmplementeerd door ik lees de commentaren en zie duidelijke hiaten erin.
• Als ik de echte code invul, heb ik commentaar waarin in het Engels wordt uitgelegd wat ik aan het doen ben. (Ze hebben het waarschijnlijk nodig als het zo ingewikkeld is dat ik eerst pseudo-code moet schrijven).

Over stroomdiagrammen

Code verandert typisch zo veel dat stroomdiagrammen niet nuttig zijn, behalve voor grotere, meer systeembrede architectuur ontwerp of documentatie. In die gevallen zal ik gewoon een diagram whiteboard om de kern van dingen te krijgen of om aan iemand anders in het team te laten zien. Tenzij je echt een stroomdiagram nodig hebt om je te helpen begrijpen, heb je ze niet echt nodig om software te doen . Rechtsaf. Tegenwoordig zijn er veel plug-ins voor IDEs die stroomdiagrammen genereren op basis van de code zelf, evenals klassendiagrammen en andere (en vice versa `). De enige echte tijd die je nodig hebt om een serieus nauwkeurig stroomschema te maken, is als je niet de hele architectuur en hoe de dingen in één keer in je hoofd kunnen houden en door iets visueels moet praten om knikken op te vangen.

Over het algemeen schrijf ik geen stroomdiagrammen terwijl ik aan persoonlijke projecten werk (aangezien projecten niet zo groot zijn) en de meeste invoer, uitvoer en processen zijn duidelijk.

maar aangezien je aan complexe grote projecten gaat werken met verschillende invoerbronnen, zijn platte bestanden, databases, handmatige interfaces enz. stroomdiagrammen handig.

Ik zou het aanraden je schrijft pseudocode en UML-digrammen, aangezien deze tools je zullen helpen om betere klassen, methoden enz. te bedenken. Soms zul je tijdens het schrijven van pseudocode andere en efficiëntere manieren vinden om een programma op te lossen.

Pseudocode is bedoeld om snel een idee weer te geven aan degenen die op zijn minst de basisprincipes van code begrijpen. Stroomdiagrammen zijn fr het tekenen van mooie plaatjes voor alle anderen om hetzelfde te begrijpen.

Stroomdiagrammen worden vaak gebruikt voor documentatiedoeleinden omdat veel verschillende mensen die documentatie gebruiken en stroomdiagrammen zijn gemakkelijker te volg dan pseudo-code voor niet-programmeurs. In een project waaraan je voor jezelf werkt, is het prima om pseudocode te gebruiken, omdat het veel nuttiger en veel gemakkelijker te maken is, omdat je alleen een teksteditor nodig hebt.

Stroomdiagrammen zijn een hoog abstractieniveau, ze laten je plannen hoe de dingen moeten verlopen, bijvoorbeeld

als x dies y wins

Ze hoeven niet afhankelijk te zijn van hoe je het programma ontwerpt in termen van klassen en methoden, pseudocode aan de andere kant een lager abstractieniveau bieden (hoewel het er echt van afhangt)

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

dus pseudocode kan nu worden vertaald in een echt programma op basis van de taal die je gebruikt.

Voor een game zou ik aanraden om eerst een stroomschema te gebruiken en daarna de klassen en methoden, schrijf pseudocode en converteer dat uiteindelijk naar een programma

Ik zou denk na over de aard van de code die u schrijft. Als het:

1. Zeer iteratief / recursief
2. Vertakkingen op gecompliceerde manieren
3. Geïmplementeerd in verschillende systemen, die u wilt vertegenwoordigen

In de eerste twee gevallen wordt pseudocode steeds moeilijker te lezen dan een grote afbeelding. Aan de andere kant, code die meestal lineair is, maakt ongelooflijk saaie diagrammen die het proces eigenlijk moeilijker te begrijpen maken, omdat het het opblaast.

In het derde geval zijn stroomdiagrammen beter in het weergeven van processen die overschrijdt systeemgrenzen en vertegenwoordigt het hele proces.

1. Je moet gebruiken waar je je prettig bij voelt. Dat gezegd hebbende, heb ik de indruk dat stroomdiagrammen tegenwoordig niet veel worden gebruikt om programmabesturing te schetsen; Ten eerste zijn ze typisch ongestructureerd, vergeleken met pseudocode. Het is gebruikelijker om klasse-afhankelijkheidsdiagrammen zoals UML te gebruiken om uw architectuur op een veel hoger niveau te beschrijven. Als je applicatie een toestandsmachine heeft, is het ook essentieel om een (stroomschema-achtig) toestandsmachinediagram te tekenen.
2. Ik denk dat je hier gelijk hebt. Een manier om te werken is om uw pseudocode als commentaar in uw bronbestand te schrijven en de daadwerkelijke implementatieregels ertussen in te voegen.
3. Nogmaals, gebruik alles waar u zich prettig bij voelt. Als je het niet zeker weet, probeer ze dan allebei uit; ik verwacht dat je praktijk snel zal convergeren in wat voor jou het nuttigst is. Persoonlijk vind ik stroomdiagrammen niet nuttig, tenzij ik probeer een bijzonder gecompliceerde executoriale titel te ontwarren.

Waarom pseudocode schrijven als je Java kunt schrijven? Ik heb Java gevonden, een goede IDE en Javadoc is de gemakkelijkste manier om een programmeerprobleem te begrijpen – tenminste een objectgeoriënteerd probleem. (En een arcadespel zou moeten zijn.) De taal is hiervoor vanaf de grond af ontworpen. Het is eenvoudig en duidelijk. (Misschien te simpel voor veel doeleinden, maar het beste wat ik hiervoor heb gezien.) De hypertekst in de Javadoc en, via een IDE, in de code zelf, zorgen voor een begrijpelijker diagram dan waarop je zelfs zou kunnen tekenen. een groot vel papier. Java-code is net zo eenvoudig als elke pseudocode en een stuk strenger. En als je het eenmaal “schematisch” en “pseudo” gecodeerd hebt, zal het programma daadwerkelijk worden uitgevoerd!

Reacties

• java en anderen kunnen langdradig zijn. ” public static void main .. ” of ” system.out.println ” of lange identifiers met camelback-notatie, langdradig daar.n dan uitzonderingen dat hebben 2b gevangen .. En het bellen van bibliotheken kan langdradig zijn. Ik herinner me 10 jaar geleden dat ik een bestand opende. zoiets als nieuwe BufferedReader (nieuwe InputStreamReader (System.in)); blijkbaar gemakkelijker nu mkyong.com / java / … Maar eigenlijk kan elke bibliotheek die u aanroept langdradig zijn, niet als pseudocode die zo beknopt kan zijn als u zich kunt voorstellen
• ook in java of welke taal dan ook, je raakt fouten tijdens het compileren. niets van dat alles met pseudocode. je kunt je concentreren op design zonder afleiding. Opmerkingen over pseudocode kunnen veel korter zijn aangezien pseudocode duidelijker is voor de geest aangezien het ‘ uit de geest komt. Je ‘ wordt niet beperkt door in slechts één taal te denken, en je zou kunnen zien dat ah i ‘ deze andere taal zal gebruiken. Het ‘ is sneller en minder pijnlijk om te schrijven (geen compilaties nodig – zelfs de zeer vloeiende compilatiefouten) en dus minder tijd om te schrijven maakt het gemakkelijker om opnieuw te ontwerpen.
• @barlop: het werkt voor mij, maar het werkt misschien niet voor iedereen. Ik laat veel code (” BufferedReader “, bijvoorbeeld) uit mijn lessen totdat ik het nodig heb of moet weten of ik kan het laten werken. Zelfs als ik het heb, is het ‘ netjes opgeborgen in klassen waar ik ‘ niet naar hoef te kijken als ik over het algemeen nadenk ontwerp. Compilerfouten zijn gemakkelijk te verhelpen en kunnen grote ontwerpfouten voorkomen, zoals het gebruik van de verkeerde klasse op een punt waarop u ‘ zelfs krijgt een instantie van de juiste klasse. Ik geef toe, ik heb ” ” software ontworpen op deze manier die alleen worden geschreven in Java, maar het OP maakt gebruik van Java.
• zeg je dat je een bestand wilt openen, zie je hoe pseudocode van openfile (” c: \ blah \ file “) is korter dan de Java om het te doen? of dat print ” dfdfd ” korter is dan de Java om dit te doen? Ik ‘ heb (nog) nooit paginas met pseudocode en meerdere klassen gemaakt. gedeeltelijk ‘ omdat ik ‘ heb geschreven in grote programmas in tijden b) gedeeltelijk ‘ cos Ik denk niet dat ik ‘ niet zou denken, ik denk dat ik ‘ een pseudocode zou schrijven en het vervolgens zou laten implementeren. Elke andere pseudocode, als die er is, zou een hoger niveau hebben. Ik heb misschien een lijst met alle klassen en methoden, inclusief constructors. Dus ik weet welke klassen wat zijn en dat ik er een instantie van kan krijgen ..
• dus ik zou niet ‘ in een situatie verkeren waarin ik de verkeerde klasse gebruik maar hoe dan ook, als het ‘ mijn programma is, dan heb ik ‘ in mijn aantekeningen opgeschreven welke klasse is wat … klassen zijn mooi hoog niveau. ik ‘ zou daar een opmerking over hebben als ik ‘ het niet kan onthouden. En pseudocode gaat helemaal over wat men bedoelt, dus als je een instantie van class blah wilde maken en je schreef bleh, dan is het ‘ slechts een typefout, maar het is niet ‘ hinderen uw ontwerp niet. (als je ‘ voor jezelf schrijft ‘ omdat je begrijpt wat je bedoelt, en je hebt het als een klap gebruikt).

Je zou een stroomdiagram kunnen gebruiken als je echt in de war raakt door if-uitspraken en je probeert het te begrijpen dat. Of als je een lus probeert te begrijpen, kijk dan naar het effect van tellers. Als je aan het leren bent, kan het veel helpen.

Het kan een beetje beperkend aanvoelen “omdat je korte uitspraken in kaders moet plaatsen. En als je programma erg lineair is en je loops en ifs triviaal zijn, dan zie ik er geen nut voor.

Pseudocode is handig voor het ontwerpen van een programma. zonder de afleiding van de juiste syntaxis en zonder de langdradigheid die sommige talen met zich meebrengen. Het feit dat het sneller is om te schrijven, maakt het ook gemakkelijker om opnieuw te ontwerpen code. En u kunt zo beknopt zijn als uw geest wenst, het is prettig om te schrijven, het vereist minder mentale inspanning om het werkend te krijgen (zoals geen of veel minder foutopsporing) en meer vermogen om u te concentreren op het grote geheel en het ontwerp.

Dus handig voor jezelf.

Ze kunnen ook worden gebruikt om met anderen te communiceren.