Quand utiliserais-je un pseudocode au lieu dun organigramme?

Fl owcharts et pseudocode ont souvent le même niveau dexpressivité, mais diffèrent dans la linéarisation. Le pseudocode est linéaire (cest-à-dire une séquence de lignes avec des instructions), un organigramme ne lest pas. Par conséquent, les organigrammes sont un niveau dabstraction 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. De nombreuses personnes non techniques ont une forte peur du texte structuré, mais pas des descriptions graphiques, donc les organigrammes seront beaucoup plus agréables avec eux. Deuxièmement, les organigrammes sont bien meilleurs pour exprimer des méta-considérations telles que laffichage de la ligne principale dexécution par opposition aux branches.

Vos questions en détail:

1. Pour une tâche vraiment compliquée problème, vous utiliseriez dabord les organigrammes, puis le pseudo-code. Les deux sont facultatifs lorsque vous vous sentez suffisamment en sécurité.
2. Oui, le pseudocode a lavantage dêtre fusionnable avec du vrai code. Steve McConnell, par exemple, recommande fortement décrire dabord les méthodes en pseudocode, puis de laisser le pseudo-code dans le code sous forme de commentaires.
3. Jai toujours senti que le besoin 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, ce qui doit être évité à grands frais.

Commentaires

• Les organigrammes sont également un excellent moyen pour sassurer que chaque point de décision définit les actions pour le (s) chemin (s) le (s) moins commun (s) ainsi que le plus courant. Cela permet de vous assurer que vous saurez quoi faire lorsque lapprobation est refusée ou que la commande est annulée! Il y a souvent plus de bogues dans les cas extrêmes parce que les gens oublient de les faire ou les font précipitamment pendant le contrôle qualité lorsque les tests les trouvent.

Sur le pseudo-code

Pour être honnête, je nutilise pas beaucoup le pseudo-code. En général, il est plus rapide décrire simplement le code, de sorte que lorsque jen ai fini avec mon code, cest le 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 décomposer la structure dune méthode ou quelque chose. Dans ces cas, jutilise des commentaires dans mon IDE pour mettre en page la structure jusquà ce que je fasse les choses correctement. Ensuite, jécris le code réel dans les commentaires. Cela maide à faire plusieurs choses:

• Je peux voir les zones que jai et que je nai pas implémentées par lire les commentaires et voir des lacunes évidentes.
• Lorsque je remplis le vrai code, jai des commentaires expliquant en anglais ce que je fais. (Ils en auront probablement besoin si cest si compliqué que jai besoin décrire dabord le pseudo-code).

Sur les organigrammes

Le code change généralement tellement que les organigrammes ne sont pas utiles, sauf pour une architecture plus large et plus à léchelle du système conception ou documentation. Dans ces cas, je vais simplement afficher un diagramme sur un tableau blanc pour comprendre lessentiel des choses ou pour le montrer à quelquun dautre dans léquipe. À moins que vous nayez vraiment besoin dun organigramme pour vous aider à comprendre, vous nen avez pas vraiment besoin pour « faire » un logiciel droit. 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 moment réel dont vous auriez besoin pour faire un organigramme sérieusement précis est si vous ne pouvez pas garder larchitecture entière et comment les choses fonctionnent dans votre tête à la fois et avez besoin de parler à travers quelque chose de visuel pour attraper les problèmes.

En général, je nécris pas de diagramme 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 allez commencer à travailler sur de gros projets complexes avec différentes sources dentrée, les fichiers plats, les bases de données, les interfaces manuelles, etc., les organigrammes sont pratiques.

Je recommanderais vous écrivez du pseudo code et des digrammes UML car ces outils vous aideront à trouver de meilleures classes, méthodes, etc. Parfois, en écrivant du pseudo code, vous trouverez des moyens différents et plus efficaces de résoudre un programme.

Le pseudo-code sert à représenter rapidement une idée à ceux qui comprennent au moins les bases du code. Les organigrammes dessinent de jolies images pour tout le monde pour comprendre 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 pour vous-même, vous en tenir au pseudo-code est 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 haut niveau dabstraction, ils vous permettent de planifier comment les choses doivent se dérouler, par exemple

si x meurt y gagne

Ils nont pas besoin de dépendre de la façon dont vous concevez le programme en termes de classes et de méthodes, pseudo-code dautre part fournir un niveau dabstraction 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 dutiliser dabord un organigramme, puis de concevoir les classes et les méthodes, écrivez un pseudo-code et finalement convertissez-le en programme

Je veux d considérez la nature du code que vous écrivez. Si cest:

1. Hautement itératif / récursif
2. Branches de manière compliquée
3. Implémentée dans plusieurs systèmes, que vous souhaitez représenter

Dans les deux premiers cas, le pseudo-code devient progressivement plus difficile à lire quun grand diagramme. Dun autre côté, le code qui est principalement linéaire rend les diagrammes incroyablement ennuyeux qui rendent le processus plus difficile à comprendre en raison de son explosion.

Pour le troisième cas, les organigrammes sont meilleurs pour représenter les processus qui traversez les limites du système et représentez lensemble du processus.

1. Vous devez utiliser ce avec quoi vous vous sentez à laise. Cela dit, jai limpression que les organigrammes ne sont pas largement utilisés pour esquisser le contrôle des programmes de nos jours; dune part, ils sont généralement non structurés, par rapport au pseudocode. Il est plus courant dutiliser des diagrammes de dépendance de classe comme UML, pour décrire votre architecture à un niveau beaucoup plus élevé. De plus, si votre application a 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 est décrire votre pseudo-code sous forme de commentaires dans votre fichier source pour commencer, et dinsérer les lignes dimplémentation réelles entre elles.
3. Encore une fois, utilisez ce avec quoi vous vous sentez à laise. Si vous nêtes pas sûr, essayez-les tous les deux; je mattends à ce que votre pratique converge rapidement vers ce qui vous est le plus utile. Personnellement, je ne trouve pas les organigrammes utiles à moins que jessaie de démêler un ordre dexécution particulièrement compliqué.

Pourquoi écrire un pseudo-code lorsque vous pouvez écrire Java? Jai trouvé Java, un bon IDE, et Javadoc est le moyen le plus simple de saisir un problème de programmation – au moins un problème orienté objet . (Et un jeu darcade devrait être OO.) Le langage a été conçu à partir de zéro pour cela. Cest simple et direct. (Trop simple pour de nombreuses raisons, peut-être, mais la meilleure chose que jai vue pour cela.) Lhypertexte dans le Javadoc et, via un IDE, dans le code lui-même fait un « diagramme » plus compréhensible que vous ne pourriez même vous en inspirer. une grande feuille de papier. Le code Java est aussi simple que nimporte quel pseudo-code et beaucoup plus rigoureux. Et une fois que vous lavez « schématisé » et « pseudo » codé, le programme fonctionnera!

Commentaires

• java et autres peuvent être longs.  » public static void main ..  » ou  » system.out.println  » ou de longs identifiants avec notation camelback, long enroulés là-bas.n puis exceptions qui avoir attrapé 2b..Et appeler nimporte quelle bibliothèque peut être long. Je me souviens quil y a 10 ans, jai ouvert un fichier. quelque chose comme new BufferedReader (new InputStreamReader (System.in)); apparemment plus facile maintenant mkyong.com / java / … Mais en réalité, toute bibliothèque que vous appelez pourrait être longue, pas comme un pseudocode qui peut être aussi concis que vous pouvez limaginer
• également en java ou dans nimporte quelle langue, vous rencontrez des erreurs lors de la compilation. rien de tout cela avec pseudocode. vous pouvez vous concentrer sur le design sans aucune distraction. Les commentaires sur le pseudo-code peuvent être beaucoup plus brefs car le pseudocode est plus clair pour lesprit car il ‘ provient de lesprit. Vous ‘ nêtes pas limité en pensant à une seule langue, et vous pourriez voir que ‘ utiliser cette autre langue. Il est ‘ plus rapide et moins pénible à écrire (aucune compilation nécessaire – même les erreurs de compilation très courantes) et donc moins de temps à écrire facilite la refonte.
• @barlop: Cela fonctionne pour moi, mais cela peut ne pas fonctionner pour tout le monde. Je laisse beaucoup de code ( » BufferedReader « , par exemple) hors de mes cours jusquà ce que jen ai besoin ou que jaie besoin de savoir si je peut le faire fonctionner. Même quand je lai, il ‘ est bien caché dans les classes que je ne ‘ pas besoin de regarder quand on considère globalement conception. Les erreurs du compilateur sont facilement corrigées et peuvent éviter des défauts de conception majeurs, comme lutilisation de la mauvaise classe à un moment où vous pouvez ‘ t même obtenir une instance de bonne classe. Jadmets que jai  » conçu un logiciel  » de cette façon qui ne pourrait que être écrit en Java, mais lOP utilise Java.
• alors disons que vous voulez ouvrir un fichier, voyez-vous comment le pseudocode de openfile ( » c: \ blah \ file « ) est plus court que le java pour le faire? ou que print  » dfdfd  » est plus court que le java pour le faire? Je ‘ nai jamais (encore) fait de pages de pseudocode et de classes multiples. en partie ‘ cos je nai ‘ que de gros programmes écrits à des âges b) en partie ‘ cos Je ne ‘ t pense que je le ferais, je pense que je ‘ d écrire un pseudocode puis le mettre en œuvre. Tout autre pseudocode, sil y en a, serait de niveau supérieur. Je pourrais avoir une liste de toutes les classes et méthodes, y compris les constructeurs. Je sais donc quelles sont les classes et que je peux en obtenir une instance ..
• donc je ne serais pas ‘ dans une situation dutilisation de la mauvaise classe mais de toute façon, si ‘ est mon programme, jai ‘ écrit dans mes notes quelle classe est quoi .. les classes sont jolies haut niveau. Je ‘ a une note à ce sujet si je ne peux ‘ men souvenir. Et le pseudocode est tout à propos de ce que lon veut dire, donc si vous vouliez créer une instance de class blah et que vous avez écrit bleh, alors ‘ est juste une faute décriture mais ce nest pas le cas ‘ t entraver votre conception. (si vous ‘ réécrivez pour vous-même ‘ car vous savez ce que vous voulez dire et vous lavez utilisé comme un bla).

Vous pouvez utiliser un organigramme si vous êtes vraiment confus par les déclarations if et que vous essayez de comprendre cette. Ou si vous essayez de comprendre une boucle, voyez leffet des compteurs. Si vous apprenez, cela peut beaucoup aider.

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

Le pseudocode est utile pour concevoir un programme. sans la distraction davoir à obtenir la bonne syntaxe, et sans la lenteur que certains langages peuvent impliquer. Le fait quil soit plus rapide à écrire facilite également la refonte code. Et vous pouvez être aussi concis que votre esprit le désire, cest agréable à écrire, cela nécessite moins deffort mental pour le faire fonctionner (car pas ou beaucoup moins de débogage), et plus de capacité à se concentrer sur la grande image et la conception.

Donc, utile pour vous-même.

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