Pseudocódigo e Diagramas de Blocos (Usar ou não usar?)

Gostaria da opinião de vocês sobre esta dúvida que tenho: Pseudocódigo e Diagramas de Blocos são apenas abordagens didáticas que visam facilitar a imersão do iniciante no mundo da programação? Ou o correto seria o programador sempre escrever um pseudocódigo antes do código?

up!

Irmão, pseudo código pode ser uma faca de dois gumes.
Diagrama de blocos (…)

Na minha opinião as duas metodologias são invenção de quem não tem o que fazer e quer aparecer.

Dentre as melhores práticas de programação, procure adotar as que realmente são efetivas:
Análise do Processo e Diagrama de Classe Genérico.

Valeu, doravan!

Alguém mais?

se você estiver em um ambiente aonde todos sabem uma linguagem em especifico não vejo por que não usa-la.

Agora se for para descrever um processo para um terceiro, sem conhecimento previo de suas qualificações, ai sim, seria interessante o uso do pseudocódigo

rapaz, o problema do pseudocódigo reside no problema de sintaxe da linguagem.
Tudo bem que o pseudocódigo é bem genérico, dependendo das convenções utilizadas. Porém atenha-se ao fato que algumas keywords são idênticas em algumas linguagens, porém as suas funções são completamente distintas.
Creio que seja melhor utilizar a própria linguagem, caso a equipe fale a mesma língua, ou seja utilizada uma convenção baseada em portugol.

agora vi que meu texto tem duplo sentido …

no caso quis falar exatamente isso, se todos conhecem uma linguagem, tipo java, usar a propria linguagem para descrever algo

senao usar o pseudocodigo …

Deve-se sempre achar a forma mais adequada para especificar o problema.

Um único tipo de diagrama para fazer especificação é como achar que tudo é um prego - já que a única ferramenta que você tem é um martelo :slight_smile:

É por isso que o UML tem vários tipos diferentes de diagramas disponíveis. (Mas você não precisa e não deve se limitar aos diagramas disponíveis na UML).

Por exemplo, fluxogramas e pseudocódigo são excelentes para você escrever 70% a 80% dos algoritmos simples que existem por aí - e é por isso que muita gente indica que os programadores (principalmente os iniciantes) os escrevam - eu costumo, por exemplo, sempre deixar um pseudocódigo no cabeçalho de meus programas.

Mas muitas vezes você precisa de um diagrama de estado (quando o seu fluxograma começa a ficar muito complicado, provavelmente um diagrama de estado será mais apropriado), ou de alguma notação matemática qualquer, ou mesmo de uma simples tabela de mapeamento.

Diagramas de fluxo de dados (que estavam muito na moda), de entidade-relacionamento etc. são importantes também.

O importante é sempre ter alguma coisa documentada que não seja código puro.

O código puro em Java contém muita “burocracia” que distorce a intenção de quem especificou o problema. E é por isso que ponho um pseudo-código no cabeçalho de muitos programas meus, porque aí eu elimino a parte “burocrática” e deixo só a “intenção”.

Outras linguagens são menos burocráticas, mas às vezes podemos ter o caso contrário - o programa é incompreensível se você não deixar um monte de comentários, referindo-se a algum diagrama que o explique. Isso costuma ocorrer muito em linguagens funcionais como Haskell.

Na minha opinião,

Para quem é iniciante deve-se fazer pseudocodigo e diagrama de blocos sim, principalmente para aqueles exercicios escolares, do tipo: fazer uma calculadora, calculo de IMC, somar 3 valores e dividir pelo 2º valor…

Porém com o tempo você vai adquirindo experiência (lógica) e consegue desenvolver diretamente na linguagem de programação, coisas do tipo: popular uma matriz, estruturas de repetição junto com estruturas de seleção, enfim…

Depois você aprender a programar bem e resolver desenvolver um sistema de para gerenciamento de biblioteca (ou algum destes clássicos), então você terá que desenvolver os casos de uso, diagrama de maquina de estado, de classes etc. Mas isso não quer dizer (na minha opinião) que pseudocodigo, diagrama de blocos, fluxograma entre outros não são utéis, pois algumas vezes, se você desenvolve-se eles primeiramente seria mais facil :smiley: :smiley: :smiley:

Programador tem que escrever código legível. Em um produto de software, o único valor que existe é o código. Tudo o mais é custo. Assim, diagramas, pseudo-código, etc. devem ser usados pelo programadores somente se a legibilidade do código estiver comprometida de alguma maneira. Na verdade, eles são mais úteis em etapas de análise, que é quando você precisa modelar algum domínio e coisas do tipo. Mas na hora da implementação mesmo, acho desnecessário.

Obrigado pelas contribuições.

Apesar de já ter estudado pseudocódigo e diagramas de blocos quando comecei a estudar programação, já esqueci da maior parte dos comandos e da simbologia por nunca mais ter feito uso dos mesmos. É assim com vocês também? Pergunto isso porque me falta vontade para rever esses assuntos, e acho que meu tempo seria muito melhor aproveitado se eu o usasse para estudar coisas mais importantes.

[quote=invader_zim]Obrigado pelas contribuições.

Apesar de já ter estudado pseudocódigo e diagramas de blocos quando comecei a estudar programação, já esqueci da maior parte dos comandos e da simbologia por nunca mais ter feito uso dos mesmos. É assim com vocês também? Pergunto isso porque me falta vontade para rever esses assuntos, e acho que meu tempo seria muito melhor aproveitado se eu o usasse para estudar coisas mais importantes.[/quote]

Acredite, tem coisa muito mais importante para estudar sim …

http://algoritmizando.com/desenvolvimento/algoritmos/livro-algoritmos-e-programacao-teoria-e-pratica/

Encontrei o livro do link acima que parece abordar todo esse assunto e inclui até estruturas de dados.
O que acham dele?

O sumário está abaixo.

http://www.novatec.com.br/livros/algoritmos/sumario857522073X.pdf

Pra saber se o livro é bom mesmo só lendo. Mas o conteúdo abordado é o base de qualquer programação. Me surpreende a quantidade de pessoas que chega no mercado sem os conceitos básicos aprendidos nesse livro.

É por isso que me preocupo tanto com esse assunto. Na disciplina de programação I, na universidade, o meu professor simplesmente pulou esses assuntos e foi direto para a linguagem C. Isso sem falar que ele passou voando pelos conteúdos de programação I e perdeu mais de meio semestre tentando ensinar conteúdos da disciplina de programação II (Alocação dinâmica de memória, manipulação de arquivos, etc).

Resultado disso tudo: Boa parte da turma está sofrendo em programação II, que nem é uma matéria tão difícil.

Discordo fortemente da frase em negrito. Primeiro que código é custo. Custo é todo desembolso associado ao desenvolvimento do produto, áreas meio como contas a pagar, marketing, rh e etc são despesas administrativas.

Além do que o conceito de valor está associado a percepção do cliente, então não entendi o que você quis dizer com a frase, no conceito original, quem gera maior valor normalmente é quem está atribuído a área de serviços/marketing. Mas se o que você disse for relacionado a “matéria prima”/core do produto. Design, banco de dados, gestão de projetos e testes são tão matérias primas e produtos de trabalho do software quanto o código.

[quote=invader_zim]http://algoritmizando.com/desenvolvimento/algoritmos/livro-algoritmos-e-programacao-teoria-e-pratica/

Encontrei o livro do link acima que parece abordar todo esse assunto e inclui até estruturas de dados.
O que acham dele?

O sumário está abaixo.

http://www.novatec.com.br/livros/algoritmos/sumario857522073X.pdf[/quote]

Alguém indica outro bom livro na mesma linha do citado acima???

[quote=doravan]Irmão, pseudo código pode ser uma faca de dois gumes.
Diagrama de blocos (…)

Na minha opinião as duas metodologias são invenção de quem não tem o que fazer e quer aparecer.

Dentre as melhores práticas de programação, procure adotar as que realmente são efetivas:
Análise do Processo e Diagrama de Classe Genérico.[/quote]

Nem sempre quando a ideia para solucionar um problema aparece eu estou de frente a um PC.
Eu acho o pseudocodigo uma boa nesta hora.
Sou viciado no auto completar e como trabalho com 3 linguagens é dificil lembrar como é a função tal.

Diagramas são uma boa se lhe ajudar a visualizar a solução e principalmente se tiver que passar a explicação para algum outro colega.