Quand utiliserais-je un pseudocode au lieu d'un organigramme?

Je suis un étudiant travaillant avec diverses techniques de programmation et j'ai rencontré un pseudocode et un organigramme. Je sais que ceux-ci sont tous deux utilisés afin de réfléchir au problème avant de réellement programmer, mais j'ai quelques questions à ce sujet.

1. Quand utiliserais-je un pseudocode pour planifier et quand utiliserais-je des organigrammes? Ou est-il préférable de faire les deux avant de réellement programmer. Particulièrement pour une petite sorte de jeu d'arcade en JAVA puisque c'est mon prochain projet.
2. J'ai remarqué que le pseudocode est très similaire au code réel plutôt qu'aux organigrammes. Est-ce que cela améliorerait le pseudocodage parce que vous copiez / collez essentiellement le pseudocode dans votre programme (bien sûr, vous devez le changer pour l'adapter à la langue. Je comprends cette partie).
3. Est-il pratique d'utiliser les deux lors de la programmation? Particulièrement le même jeu mentionné précédemment. Merci.

Les organigrammes et les pseudocodes ont souvent le même niveau d'expressivité, mais diffèrent par leur linéarisation. Le pseudocode est linéaire (c'est-à-dire une séquence de lignes avec des instructions), un organigramme ne l'est pas. Par conséquent, les organigrammes sont un niveau d'abstraction plus élevé, utilisé avant d'écrire un pseudocode ou pour la documentation.

Les organigrammes ont, à mon avis, deux avantages importants par rapport au pseudocode: premièrement, ils sont graphiques. Beaucoup de personnes non techniques ont une forte crainte du texte structuré, mais pas des descriptions graphiques, donc les organigrammes seront plus agréables avec eux. Deuxièmement, les organigrammes sont bien meilleurs pour exprimer des méta-considérations telles que montrer la ligne principale d'exécution par opposition aux branches.

Vos questions en détail:

1. Pour un problème vraiment compliqué, vous utiliseriez d'abord les organigrammes, puis le pseudocode. Les deux sont facultatifs lorsque vous vous sentez suffisamment en sécurité.
2. Oui, le pseudocode a l'avantage d'être fusionnable avec du vrai code. Steve McConnell, par exemple, recommande fortement d'écrire les méthodes en pseudocode d'abord, puis de laisser le pseudocode dans le code en tant que commentaires.
3. J'ai toujours pensé que la nécessité de dessiner un organigramme lors de la conception montre une partition insuffisante de votre problème. Les organigrammes non triviaux indiquent une logique alambiquée, qui devrait être évitée à grands frais.

Sur le pseudo code

Pour être honnête, je n'utilise pas beaucoup le pseudocode. En règle générale, il est plus rapide d'écrire simplement le code, de sorte que lorsque j'en ai fini avec mon code, c'est du code réel. Il y a des cas où le pseudo-code peut être utile, mais vous travaillez généralement sur quelque chose de très complexe et essayez simplement de briser la structure d'une méthode ou quelque chose. Dans ces cas, j'utilise des commentaires dans mon IDE pour définir la structure jusqu'à ce que les choses se passent bien. Ensuite, j'entre et j'écris le code réel dans les commentaires. Cela m'aide à faire quelques choses:

• Je peux voir les domaines que j'ai ou non mis en œuvre en lisant les commentaires et en y voyant des lacunes évidentes.
• Lorsque je remplis le vrai code, j'ai des commentaires expliquant en anglais ce que je fais. (Ils en auront probablement besoin si c'est si compliqué que je dois d'abord écrire un pseudo code).

Sur les organigrammes

Le code change généralement tellement que les organigrammes ne sont pas utiles, sauf pour une conception ou une documentation d'architecture plus large et à l'échelle du système. Dans ces cas, je vais simplement mettre un tableau blanc sur un diagramme pour obtenir l'essentiel ou montrer à quelqu'un d'autre dans l'équipe. Sauf si vous avez vraiment besoin d'un organigramme pour vous aider à comprendre, alors vous n'avez pas vraiment besoin d'eux pour «faire» correctement le logiciel. De nos jours, il existe de nombreux plugins pour les IDE qui généreront des organigrammes à partir du code lui-même, ainsi que des diagrammes de classes et autres (et vice versa `). Le seul temps réel dont vous auriez besoin pour faire un organigramme vraiment précis est si vous ne pouvez pas garder l'architecture entière et comment les choses fonctionnent dans votre tête à la fois et devez parler de quelque chose de visuel pour attraper les défauts.

En général, je n'écris pas de diagrammes pendant que je travaille sur des projets personnels (car les projets ne sont pas très gros) et la plupart des entrées, sorties et processus sont clairs.

mais comme vous commencerez à travailler sur de grands projets complexes avec différentes sources d'entrée, les fichiers plats, les bases de données, les interfaces manuelles, etc., les organigrammes sont pratiques.

Je vous recommanderais d'écrire du pseudo-code et des digrammes UML car ces outils vous aideront à trouver de meilleures classes, méthodes, etc. Parfois, lors de l'écriture d'un pseudo-code, vous trouverez des moyens différents et plus efficaces de résoudre un programme.

Le pseudo-code est pour représenter rapidement une idée à ceux qui comprennent au moins les bases du code. Les organigrammes dessinent de jolies images pour que tout le monde comprenne la même chose.

Les organigrammes sont souvent utilisés à des fins de documentation car de nombreuses personnes différentes utilisent cette documentation et les organigrammes sont plus faciles à suivre que le pseudo-code pour les non-programmeurs. Dans un projet sur lequel vous travaillez vous-même, coller avec un pseudo-code est très bien car il est beaucoup plus utile et beaucoup plus facile à créer car un éditeur de texte est tout ce dont vous avez besoin.

Les organigrammes sont un niveau d'abstraction élevé, ils vous permettent de planifier la façon dont les choses devraient se dérouler, par exemple

si x meurt y gagne

Ils n'ont pas besoin de dépendre de la façon dont vous concevez le programme en termes de classes et de méthodes, le pseudo-code d'autre part fournit un niveau d'abstraction inférieur (bien que cela dépende vraiment)

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

ainsi le pseudo code peut maintenant être traduit en programme réel basé sur la langue que vous utilisez.

Pour un jeu, je recommanderais d'abord d'utiliser un organigramme, puis de concevoir les classes et les méthodes, d'écrire un pseudo-code et enfin de le convertir en programme

Je considérerais la nature du code que vous écrivez. Si c'est:

1. Très itératif / récursif
2. Les succursales de manière compliquée
3. Implémenté dans plusieurs systèmes que vous souhaitez représenter

Dans les deux premiers cas, le pseudocode devient progressivement plus difficile à lire qu'un diagramme à grande image. D'un autre côté, un code principalement linéaire rend les diagrammes incroyablement ennuyeux qui rendent le processus plus difficile à comprendre en raison de son ampleur.

Pour le troisième cas, les organigrammes sont mieux à même de représenter les processus qui traversent les frontières du système et représentent l'ensemble du processus.

1. Vous devez utiliser tout ce qui vous convient. Cela dit, j'ai l'impression que les organigrammes ne sont pas largement utilisés pour esquisser le contrôle des programmes de nos jours; d'une part, ils sont généralement non structurés, par rapport au pseudocode. Il est plus courant d'utiliser des diagrammes de dépendance de classe comme UML pour décrire votre architecture à un niveau beaucoup plus élevé. De plus, si votre application dispose d'une machine à états, il est essentiel de dessiner un diagramme de machine à états (semblable à un organigramme).
2. Je pense que vous avez raison ici. Une façon de travailler consiste à écrire votre pseudocode sous forme de commentaires dans votre fichier source pour commencer et à insérer les lignes d'implémentation réelles entre elles.
3. Encore une fois, utilisez tout ce qui vous convient. Si vous n'êtes pas sûr, essayez-les tous les deux; J'espère que votre pratique convergera rapidement vers ce qui vous sera le plus utile. Personnellement, je ne trouve pas les organigrammes utiles à moins que j'essaie de démêler un ordre d'exécution particulièrement compliqué.

Pourquoi écrire du pseudo-code quand on peut écrire Java? J'ai trouvé Java, un bon IDE et Javadoc sont le moyen le plus simple de saisir un problème de programmation - au moins un problème orienté objet . (Et un jeu d'arcade devrait être OO.) Le langage a été conçu à partir de zéro pour cela. C'est simple et direct. (Trop simple à de nombreuses fins, peut-être, mais la meilleure chose que j'ai vue à ce sujet.) L'hypertexte dans le Javadoc et, via un IDE, dans le code lui-même font un "diagramme" plus compréhensible que vous ne pourriez en tirer même une grande feuille de papier. Le code Java est aussi simple que n'importe quel pseudo-code et beaucoup plus rigoureux. Et une fois que vous l'avez "schématisé" et "pseudo" codé, le programme s'exécutera!

Vous pouvez utiliser un organigramme si vous êtes vraiment dérouté par les instructions if et que vous essayez de comprendre cela. Ou si vous essayez de comprendre une boucle, voyez l'effet des compteurs. Si vous apprenez, cela peut beaucoup aider.

Cela peut sembler un peu restrictif, car vous devez mettre de brèves déclarations dans des boîtes. Et si votre programme est très linéaire et vos boucles et ifs sont triviaux, alors je ne vois aucune utilité.

Le pseudocode est utile pour concevoir un programme. Sans la distraction d'avoir à obtenir la bonne syntaxe, et sans la lourdeur que certains langages peuvent impliquer. Le fait qu'il soit plus rapide à écrire facilite également la refonte du code. Et vous pouvez être aussi concis que votre esprit le souhaite, il est agréable à écrire, nécessite moins d'effort mental pour le faire fonctionner (comme pas ou beaucoup moins de débogage), et plus de capacité à se concentrer sur la grande image et le design.

Donc, utile pour vous.

Ils peuvent également être utilisés pour communiquer avec les autres.