Quando devo usar o pseudocódigo em vez do fluxograma?

Fl owcharts e pseudocódigo geralmente têm o mesmo nível de expressividade, mas diferem na linearização. O pseudocódigo é linear (ou seja, uma sequência de linhas com instruções), um fluxograma não. Portanto, fluxogramas são um nível de abstração mais alto, usados antes de escrever pseudocódigo ou para documentação.

Os fluxogramas têm, em minha opinião, duas grandes vantagens sobre o pseudocódigo: Em primeiro lugar, eles são gráficos. Muitas pessoas que não são técnicas têm um grande medo de texto estruturado, mas não de descrições gráficas, então os fluxogramas ficarão muito mais agradáveis com eles. Em segundo lugar, os fluxogramas são muito melhores para expressar metaconsiderações, como mostrar a linha principal de execução em vez de ramos.

Suas perguntas em detalhes:

1. Para um estudo realmente complicado problema, você usaria fluxogramas primeiro e, em seguida, pseudocódigo. Ambos são opcionais quando você se sente seguro o suficiente.
2. Sim, o pseudocódigo tem a vantagem de poder ser mesclado com o código real. Steve McConnell, por exemplo, recomenda fortemente escrever métodos em pseudocódigo primeiro e depois deixar o pseudocódigo no código como comentários.
3. Sempre achei que a necessidade de desenhar um fluxograma durante o design mostra uma partição insuficiente do seu problema. Fluxogramas não triviais indicam lógica complicada, que deve ser evitada com grandes custos.

Comentários

• Fluxogramas também são ótimas maneiras para certificar-se de que cada ponto de decisão defina as ações para os caminhos menos comuns, bem como para os mais comuns. Isso ajuda a garantir que você saiba o que fazer quando a aprovação for negada ou o pedido for cancelado! Freqüentemente, há mais bugs nos casos extremos porque as pessoas se esquecem de fazê-los ou os fazem com pressa durante o controle de qualidade quando o teste os encontra.

No pseudocódigo

Para ser honesto, eu não uso muito o pseudocódigo. Normalmente, é mais rápido apenas escrever o código, de modo que, quando terminar meu código, é o código real. Existem alguns casos em que o pseudo código pode ser útil, mas geralmente você está trabalhando em algo muito complexo e apenas tentando quebrar a estrutura de um método ou algo assim. Nesses casos, uso comentários em meu IDE para definir a estrutura até que eu acerte as coisas. Então, eu entro e escrevo o código real nos comentários. Isso me ajuda a fazer algumas coisas:

• Posso ver áreas que tenho e não implementadas por lendo os comentários e vendo lacunas óbvias neles.
• Quando eu preencho o código real, eu tenho comentários explicando em inglês o que estou fazendo. (Eles provavelmente vão precisar se for tão complicado que preciso escrever primeiro pseudocódigo).

Nos fluxogramas

O código normalmente muda tanto que os fluxogramas não são úteis, exceto para uma arquitetura maior e mais abrangente do sistema design ou documentação. Nesses casos, vou apenas colocar um diagrama no quadro branco para obter a essência das coisas ou para mostrar a alguém da equipe. A menos que você realmente precise de um fluxograma para ajudá-lo a entender, então você realmente não precisa que eles “façam” software direita. Hoje em dia, existem muitos plug-ins para IDEs que irão gerar fluxogramas a partir do próprio código, bem como diagramas de classes e outros (e vice-versa `). O único momento real em que você precisaria fazer um fluxograma seriamente preciso é se não conseguir manter toda a arquitetura e como as coisas funcionam em sua cabeça de uma vez e precisar falar por meio de algo visual para detectar problemas.

Geralmente eu não escrevo fluxogramas enquanto estou trabalhando em projetos pessoais (pois os projetos não são muito grandes) e a maioria das entradas, saídas e processos são claros.

mas como você vai começar a trabalhar em grandes projetos complexos com diferentes fontes de entrada, arquivos simples, bancos de dados, interfaces manuais etc. fluxogramas são úteis.

Eu recomendaria você escrever pseudo código e digramas UML, pois essas ferramentas irão ajudá-lo a criar melhores classes, métodos, etc. Às vezes, ao escrever pseudo código, você encontrará maneiras diferentes e mais eficientes de resolver um programa.

O pseudocódigo serve para representar rapidamente uma ideia para aqueles que entendem pelo menos o básico do código. Fluxogramas são para desenhar imagens bonitas para todos os outros para entender a mesma coisa.

Os fluxogramas são frequentemente usados para fins de documentação porque muitas pessoas diferentes usam essa documentação e os fluxogramas são mais fáceis de siga que o pseudo código para não programadores. Em um projeto no qual você está trabalhando para si mesmo, ficar com pseudocódigo está bem, pois é muito mais útil e muito mais fácil de criar, pois um editor de texto é tudo de que você precisa.

Fluxogramas são um alto nível de abstração, eles permitem que você planeje como as coisas devem prosseguir, por exemplo

se x morre y ganha

Eles não precisam depender de como você está projetando o programa em termos de classes e métodos, pseudo código, por outro lado fornece um nível inferior de abstração (embora realmente dependa)

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

portanto, o pseudocódigo agora pode ser traduzido em um programa real com base na linguagem que você está usando.

Para um jogo, eu recomendaria usar um fluxograma primeiro e depois projetar as classes e métodos, escreva pseudocódigo e, finalmente, converta-o em um programa

Eu gostaria d considere a natureza do código que você está escrevendo. Se for:

1. Altamente iterativo / recursivo
2. Ramificações de maneiras complicadas
3. Implementado em vários sistemas, que você deseja representar

Nos primeiros dois casos, o pseudocódigo se torna cada vez mais difícil de ler do que um diagrama grande. Por outro lado, o código que é principalmente linear cria diagramas incrivelmente enfadonhos que tornam o processo mais difícil de entender por causa do quanto ele explode.

Para o terceiro caso, os fluxogramas são melhores para representar processos que cruze os limites do sistema e represente todo o processo.

1. Você deve usar o que quiser. Dito isso, minha impressão é que os fluxogramas não são muito usados para esboçar o controle do programa atualmente; por um lado, eles são normalmente não estruturados, em comparação com o pseudocódigo. É mais comum usar diagramas de dependência de classe como UML, para descrever sua arquitetura em um nível muito mais alto. Além disso, se seu aplicativo tiver uma máquina de estado, desenhar um diagrama de máquina de estado (semelhante a um fluxograma) é essencial.
2. Acho que você está correto aqui. Uma maneira de trabalhar é escrever seu pseudocódigo como comentários em seu arquivo de origem, para começar, e inserir as linhas de implementação reais entre eles.
3. Mais uma vez, use aquilo com que se sentir confortável. Se você não tiver certeza, experimente os dois; espero que sua prática converta rapidamente para o que for mais útil para você. Pessoalmente, não considero fluxogramas úteis a menos que esteja tentando desvendar uma ordem de execução particularmente complicada.

Por que escrever pseudo código quando você pode escrever Java? Eu encontrei Java, um bom IDE e Javadoc são a maneira mais fácil de entender um problema de programação – pelo menos um Orientado a Objetos . (E um jogo de arcade deveria ser OO.) A linguagem foi projetada desde o início para isso. É simples e direto. (Muito simples para muitos propósitos, talvez, mas a melhor coisa que eu vi para isso.) O hipertexto no Javadoc e, por meio de um IDE, no próprio código torna-se um “diagrama” mais compreensível do que você poderia desenhar. uma grande folha de papel. O código Java é tão simples quanto qualquer pseudocódigo e muito mais rigoroso. E depois de “diagramado” e “pseudo” codificado, o programa será executado!

Comentários

• java e outros podem ser demorados. ” public static void main .. ” ou ” system.out.println ” ou identificadores longos com notação camelback, long winded there.n então exceções que ter 2b capturado .. E chamar qualquer biblioteca pode ser demorado. Lembro-me de 10 anos abrindo um arquivo. algo como novo BufferedReader (new InputStreamReader (System.in)); aparentemente mais fácil agora mkyong.com / java / … Mas, na verdade, qualquer biblioteca que você chamar pode ser prolixa, não como o pseudocódigo, que pode ser tão conciso quanto você pode imaginar
• também em java ou qualquer linguagem, você encontra erros na compilação. nada disso com pseudocódigo. você se concentra no design sem distração. Os comentários sobre o pseudocódigo podem ser muito mais breves, pois o pseudocódigo é mais claro para a mente do que ‘ sai da mente. Você ‘ não está limitado por pensar em apenas um idioma e verá que ah i ‘ usarei esse outro idioma. É ‘ mais rápido e menos penoso de escrever (sem necessidade de compilações – mesmo os muito fluentes obtêm erros de compilação) e, portanto, menos tempo para escrever torna mais fácil redesenhar.
• @barlop: Funciona para mim, mas pode não funcionar para todos. Deixo muitos códigos (” BufferedReader “, por exemplo) fora de minhas aulas até que eu precise ou precise saber se eu pode fazer funcionar. Mesmo quando eu o tenho, ele ‘ fica bem escondido nas aulas que eu não ‘ preciso examinar ao considerar o geral Projeto. Os erros do compilador são facilmente corrigidos e podem evitar grandes falhas de design, como usar a classe errada em um ponto onde você pode ‘ t até obter uma instância do classe certa. Eu admito, tenho ” projetado ” software desta forma que poderia apenas ser escrito em Java, mas o OP está usando Java.
• então digamos que você deseja abrir um arquivo, você vê como pseudocódigo de openfile (” c: \ blah \ file “) é mais curto que o java para fazer isso? ou que print ” dfdfd ” é mais curto que o java para fazê-lo? Eu ‘ nunca fiz (ainda) páginas de pseudocódigo e classes múltiplas. parcialmente ‘ porque eu não ‘ t programas grandes em idades b) parcialmente ‘ cos Eu não ‘ não acho que faria, acho que ‘ d escreveria algum pseudocódigo e, em seguida, implementaria. Qualquer outro pseudocódigo, se houver, seria de nível superior. Posso ter uma lista de todas as classes e métodos, incluindo construtores. Então, eu sei quais são as classes e posso obter uma instância delas.
• então eu não ‘ estaria em uma situação de usar a classe errada mas de qualquer forma, se ‘ é meu programa, eu ‘ d teria escrito em minhas notas que classe é o que .. classes são bonitas alto nível. i ‘ d tenho uma nota sobre isso, se eu não consigo ‘ não lembrar disso. E pseudocódigo tem tudo a ver com o que se quer dizer, então se você pretendia tornar uma instância de classe blá e escreveu bleh, então ‘ é apenas um erro de digitação, mas não ‘ não atrapalhe seu design. (se você ‘ está escrevendo para você mesmo ‘ porque você sabe o que quer dizer e o usou como um blá).

Você poderia usar um fluxograma se estiver realmente ficando confuso com as declarações if e estiver tentando entender que. Ou se você está tentando entender um loop, veja o efeito dos contadores. Se você está aprendendo, pode ajudar muito.

Pode parecer um pouco restritivo “porque você tem que colocar instruções breves em caixas. E se seu programa for muito linear e seus loops e ifs forem triviais, não vejo utilidade para isso.

O pseudocódigo é útil para projetar um programa. sem a distração de ter que acertar a sintaxe e sem a lentidão que algumas linguagens podem envolver. O fato de ser mais rápido de escrever também torna mais fácil redesenhar código. E você pode ser tão conciso quanto sua mente deseja, é agradável escrever, requer menos esforço mental para fazer funcionar (como nenhuma ou muito menos depuração) e mais capacidade de se concentrar no quadro geral e no design.

Portanto, úteis para você.

Eles também podem ser usados para se comunicar com outras pessoas.