Simon Viegas

@Caio Felipe Souza da Silva, baixa novamente o VisualG para ver. Por favor, poste o texto do código para podermos testar também.

@kgin, topzeira... Detalhe: "por que 'B' para ocupado?". Meu palpite foi que o enunciado teria sido traduzido do inglês. Esse "B" seria de "Buzy".

Não mais antiiiga, mas apenas "anterior". A versão 3.0.6.5 seria a mais recomendada. A versão 3.0.7.0 tem muitos bugs! Uma coisa não me parece necessariamente levar a outra. A sugestão de criar essas funções estaria mais no sentido de treinar e se desafiar. No dia a dia não vai fazer diferença. Abaixo fiz um código para servir referência. Daí, caso queira entender afundo, dá uma pesquisa sobre o tal código ASCII e tente entender qual a lógica utilizada. A proposta inicial seria o oposto, ou seja, a partir do estudo, segar a um algoritmo semelhante... mas creio que fazer uma engenharia reversa seja mais útil momento. algoritmo "Torna maiúsculo ou minúsculo incluíndo caracteres acentuados" //Obs.: utilitário para versão 3.0.6.5. A versão 3.0.7.0 já está corrigida const caracteresAcentuados = "a A b B á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç" funcao MinuscPlus(txt:caractere) : caractere var i, cod : inteiro c : caractere aux : caractere inicio aux <- "" para i de 1 ate Compr(txt) faca c <- Copia(txt, i, 1) cod <- (Asc(c)) se (((cod >= 65) E (cod <= 90)) OU ((cod >= 192) E (cod <= 218))) então aux <- aux + Carac(cod+32) senao aux <- aux + c fimSe fimPara retorne aux fimFuncao funcao MaiuscPlus(txt:caractere) : caractere var i, cod : inteiro c : caractere aux : caractere inicio aux <- "" para i de 1 ate Compr(txt) faca c <- Copia(txt, i, 1) cod <- (Asc(c)) se (((cod >= 97) E (cod <= 122)) OU ((cod >= 224) E (cod <= 250))) então aux <- aux + Carac(cod-32) senao aux <- aux + c fimSe fimPara retorne aux fimFuncao var x : inteiro //variável crida apenas para fazer funcionar a const. Por algum motivo só //funciona se tiver variáveis globais kkkkkkkkkkk inicio escrevaL("Original : ", caracteresAcentuados) escrevaL("Maiúsculo: ", MinuscPLus(caracteresAcentuados)) escrevaL("Minúsculo: ", MaiuscPlus(caracteresAcentuados)) escrevaL(MinuscPlus("Lógica de Programação")) escrevaL(MaiuscPlus("Lógica de Programação")) fimAlgoritmo

Se no caso só tem uma fileira, poderia utilizar um vetor para as poltronas e o número da cadeira seria a coordenada. Algo como: var poltronasB : vetor [1..10] de caractere Exemplo: algoritmo "Reservas de poltronas prum Cinema" var poltronasB : vetor [1..10] de caractere i, j : inteiro numPoltrona : inteiro inicio para i de 1 ate 10 Faca escreval("[ B", i:2, " - ", poltronasB[i], " ]") fimPara escreva("Reservar a cadeira: B") leia(numPoltrona) poltronasB[numPoltrona] <- "Ocupado" escreval("Cadeira B", numPoltrona:1, " reservada!") para i de 1 ate 10 Faca escreval("[ B", i:2, " - ", poltronasB[i], " ]") fimPara fimAlgoritmo @Caiomqc, qual o enunciado desse problema? A forma que vai implementar uma solução vai depender das característica do problema.

@Eli Almeidaa, perfeito. Então as funções foram corrigidas na versão 3.0.7.0. Não cheguei a testar nela. Utilizo por referência a versão 3.0.6.5. Obs.: a versão 3.0.7.0 tem outros problemas mais notáveis. A versão mais comum e estável é a 3.0.6.5. Usa um ou outra (ou a 2.x) vai depender da exigência do curso ou professor, por exemplo. Recomendo a 3.0.6.5 mesmo.

De boa... só o fato de revisar um pouco o tema já é interessante. Pode pular isso (ou não). Seria dizer que você estaria "extrapolando a conclusão", ou seja, o comportamento de uma função, não necessariamente vai dar indícios claros sobre o comportamento de outra função ou outro comportamento que aparenta ser igual ou análogo a outro. Uma coisa é uma coisa, outra coisa é outra coisa! Para atestar o comportamento da função Minusc(), que tal fazer testes mais objetivos nela? Por exemplo: Oh! Lá! o caractere "Á' não foi minuscularizado para "á". O problema parece está especificamente nos tais caracteres acentuados (não é certeza, mas é um excelente indício). Se um caso não funcionou, já teríamos uma boa base que a função NÃO estaria funcionando corretamente (como seria esperado idealmente*)... mas o contrário tende a muito mais não ser verdade... tipo, se fizesse alguns testes e todos tivessem dado certo, não quer dizer que a função funciona necessariamente de modo correto, pois podemos está simplesmente "testando errado" ou "não testado o suficiente" . Saca? Claro que "não ter funcionado" também pode ser por um teste errado... por ai vai. "Hum! acho que o problema são os caracteres acentuados. Vou testar eles para ver"... Achei isso (numas tabelas): á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç Oh! Lá!... 100% dos caracteres foram ignorados, ou seja, caracteres acentuados seriam como "caracteres especiais", ou seja, o VisualG interpreta como NÃO havendo uma correspondência em minúsculo ou maiúsculo, daí "retorna o próprio caractere" . Veja que até vai amadurecendo a ideia de como provavelmente essas funções funcionam. Imagino isso: ou a função retorna o que tem mapiado como correspondente (minúsculo ou maiúsculo respectivamente), ou retorna o próprio caractere. De um modo geral, nós "ABSTRAÍMOS" como funciona as funções, pois de certo modo não importaria!!! "Eu quero que ele me retorne os caracteres minúsculos ou maiúsculos e pronto". Isso é abstrair. Ao se aprofundar em temas, vai tendo noções..., o que pode ajudar a criar novas soluções de problemas que aparentemente não tem relação direta...... Ah! Mais queria que funcionasse com acentos. Tentaria ver alternativas para isso... não existe (segundo as documentações) uma função nativa (99,999% de certeza), daí poderia criar uma nova. Exemplo: algoritmo "Torna maiúsculo ou minúsculo incluíndo caracteres acentuados" funcao MinuscPlus (txt:caractere) : caractere inicio retorne "Em construção" fimFuncao funcao MaiuscPlus (txt:caractere) : caractere inicio retorne "Em construção" fimFuncao inicio escrevaL(Minusc("á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç")) escrevaL(Maiusc("á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç")) escrevaL(MinuscPLus("á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç")) escrevaL(MaiuscPlus("á Á ã Ã â Â à À é É ê Ê í Í ó Ó õ Õ ô Ô ú Ú ç Ç")) fimAlgoritmo A base tá pronta.. Só pensar em uma lógica e tentar implementar. Não queria dar spoilers, mas uma sugestão seria pesquisar inicialmente sobre as "funções nativas do VisualG". Dá uma revisada na lista e entender mais ou menos o que cada função faz... São poucas, daí é de boa. (Com a prática, já iria direto no que cito abaixo.) No caminho se depararia com "Funções de Manipulação de Strings", ora! se estou querendo tratar de caracteres (strings), iria tentar direto aí. Que por sua vez se depararia com um tal de "código ASCII"... por aí vai! Vai indo, indo... Não estou dizendo que é trivial, mas não seria nada absurdo também. Todo conhecimento vai se construindo aos poucos... a medida que vai tendo contato vai assimilando e cada vez mais "associando" coisas!!! Caso queria aventurar, fique a vontade. Sugiro que primeiro tente... não busque soluções prontas!! Pois, ao tentar e eventualmente não conseguir (não é o objetivo), ao ter acesso a uma solução, veria um: "nossa, como não pensei nisso" ou "que massa! ideia bacana"... mas é preciso tentar antes. Garanto que vale a pena tentar sozinho e fazendo testes diversos. Eu já tinha uma ideia de como poderia fazer. Um exemplo de resultado: Daí, poderia salvar as funções em algum lugar... quando for precisar utilizar elas em algum outro código no futuro, só copiar o código!!! Sobre a questão lá do professor... que tal após de ter implementado as funções alternativas demonstrar para ele o código que fez? Confesso que eu ainda queria entender o que ele quis dizer com "não funciona".

@Caiomqc, precisa também implementar as validações:

@Caiomqc, um laço dentro de outro não ordenação nada em si. O que estaria fazendo a ordenação seria o algoritmo contigo no programa , ou seja, uma sequência de passos definidas para que tenham determinado comportamento ao serem executados. Isso é uma abstração: se tem um problema, rodam-se um programa e se obtém uma solução. Assista alguns vídeos sobre laços de repetições. Vá vendo exemplos, até internalizar. É normal ter dúvidas ou dificuldades. Depois um tempo a ficha vai caindo e as "novidades" começam a ficar mais triviais. É preciso treinar para aprender a aprender mais facilmente. Sobre as trocas de valores, você precisaria entender o algoritmo relacionado. Por exemplo, dê uma boa pesquisada sobre o Bubble Sort. É bem parecido com esse algoritmo acima. De um modo geral, é preciso primeiro entender o problema: "necessidade de ordenar um vetor desordenado". Daí buscar uma solução para ele.. só que no caso aqui, uma solução já está dada, ou seja, "um algoritmo pronto (que alguém ou um grupo inventou) que tem o tal papel de ordenar um vetor". Logo, seu papel seria apenas entender como funcionar esse algoritmo e usar. Entende? Vá pesquisando e vendo exemplos. Entendendo o algoritmo de ordenação, vai entender porque e quando precisa fazer trocas de posições.

Caracteres com acentos não são tratados por nenhuma das duas funções. São ignorados. Veja: o maiúsculo de "lógica" seria "LÓGICA", mas em vez disso sai "LóGICA". (Pois "os caracteres acentuados não são tratados".) Sobre o cerne do problema: No VisualG, toda cadeia de caracteres é tratada, ou seja, funciona*. Daí precisaria entender o que ele estaria se referindo. Já conseguiu descobrir?

@Caiomqc, corrija o algoritmo para evitar o erro mencionado.

Teria que entender melhor o contexto da frase. A função em si usa esse tipo: O que, por exemplo, não funciona é para os caracteres acentuados. Poderia dar outros detalhes do que seria?

Então, o resto está no cerne do conceito de "divisível". É o resto que define se um número é divisível por outro ou não. Se x dividido por 5 tem resto 0, então x é divisível por 5. Caso contrário, não o é. É isso.

Talvez tenha verificado linha a linha incorretamente... o erro estaria nos cálculos das raízes quadradas. Ou seja: só existe raízes reais para delta maior ou igual a 0. Se delta for negativo, vai dá erro! Sugiro revisar o tema (equações do segundo grau) e adequar o algoritmo, ou seja, teria que tratar os 3 casos possíveis.

Pelo retorno da função em si, não. Não dá. Funções só retornam um valor. Uma forma seria utilizando vetores (array) ou utilizando registros (record), mas o VisualG não aceita. (Limitação da arquitetura - o desenvolvedor não implementou. No Pascal, pai do VisualG, aceita!) Entretanto é possível retornar utilizando variáveis por referência (var) nos parâmetros... falei disso esses dias aqui:

E existe função que não retorna algo em si mesma? . A pergunta que você precisaria se fazer é: qual a diferença entre função e procedimento? Já teve algum contato, mas ainda não tá claro.. né? Daí só pesquisar novamente... Para relembrar, já falamos um pouco sobre: Funções e procedimentos são basicamente a mesma coisa. Em algumas linguagens sequer tem essa diferenciação... são até apenas chamadas de "métodos". Apenas o que muda é que funções retornam valores nelas mesmas. Já os procedimentos seriam funções que não tem retorno neles mesmos. Ou seja: como eventualmente o teu método não tem retorno nele mesmo, então deveria utilizar procedimento, em vez de função. A tua ideia de dar um retorno foi válido.. assim como "precisou" colocar para "obter o retorno da função" lá utilizando o escreva(). O detalhe apenas é que era só mudar para procedimento. Outra pergunta que poderia se fazer é: oxente! eu declarei como função e defini o tipo do retorno certinho, mas não utilizei o comando retorne devolver retorno para quem invocou a função. Por que não deu erro? Resposta: quem souber morre!. Mas você entende que não faz muito sentido criar algo que retorna um valor e você não retornar um valor? É como criar uma laço de repetição que só repete uma vez. Ou criar uma estrutura de seleção onde só existe um resultado possível... etc. REFORÇANDO: Pesquise mais sobre Funções e Procedimentos. É bem simples. Como disse: são a mesma* coisa, mas precisa assimilar melhor. Faça testes e testes e vá absorvendo os detalhes e se acostumando com os comportamentos. ADENDO Veja esse exemplo de uso de função e também do uso da referência para retornar valores. algoritmo "Divisão e Potencia numa mesma função" funcao calcular_divisao_e_potencia(n1, n2:inteiro; var quociente, potencia:real) : LOGICO inicio se (n2 = 0) então retorne FALSO senao quociente <- n1/n2 potencia <- n1^n2 retorne VERDADEIRO fimSe fimFuncao var num1, num2 : inteiro quociente : real potencia : inteiro inicio escreva("Digite o primeiro número: ") leia(num1) escreva("Digite o segundo número: ") leia(num2) se (calcular_divisao_e_potencia(num1, num2, quociente, potencia)) então escrevaL("Quociente: ", quociente:1:2) escrevaL("Potência : ", potencia:1) senao escrevaL("Nâo é possível dividir por 0") fimSe fimAlgoritmo Nesse caso, eu quis que o retorno da função (nela mesma) fosse dizer se conseguiu calcular ou não, ou seja, se o numerador for zero, o computador não vai saber calcular, daí não faz a conta e retorna FALSO. E lá no programa principal, eu sei o que a função pode retornar e fiz um tratamento para cada caso. É preciso abstrair o que está disponível, no caso para os metodos... Algo como: um método pode ter retorno nele mesmo (função) ou pode não ter (procedimento). Assim como cada um destes podem ter parâmetros ou não. Assim como cada um dos eventuais parâmetros podem ser por valor ou referência... Por aí vai. Não precisa decolar. Vai testando.. "será que se eu declarar um método sem parâmetro funciona?". Vai lá e testa. Sabemos que sim... Qualquer dúvida... sempre pergunte antes a si mesmo. Imagine que outra pessoa esteja te perguntando e que você é capaz de descobrir (como qualquer um)... saca? Vá desenvolvendo a capacidade de vestir a roupa de sapo. Mas daí se persistir ou tiver alguma dúvida, vai perguntando também! ADENDO: Não me pergunte porque não tem uma "expressão" aí no se, tente entender!!! (Se é que já não entende, é claro.) Exemplo: "Tá, a função retorna FALSO ou VERDADEIRO... daí, seria como "se FALSO então" ou "se VERDADEIRO então"... Hum!... daí..... vai tentando entender. Por aí vai.

A própria pergunta já diz a origem do problema... oras! você colocou para fazer isso! Só deixar fora! se (v >= 0) E (v <= 10) então tot010 <- tot010+1 fimSe se (v%2 = 1) então sImp <- sImp+v fimSe Adendo: os pares estão no conjunto dos inteiros, e não apenas dos naturais. Além disso, 0 é par!

Cadê? Tem uma função para liberar já está pronta lá na parte 7. Qual a dúvida? Adendo: e sobre o que sugeri?

O quê não está funcionando? Veja: para encontrar um solução, é preciso entender o problema. Vamos lá: 1. a função é dentro do algoritmo. Você colocou antes; 2. você não definiu o retorno da função. Ou se não vai ter retorno, mude para procedimento; 3. faltou o comando inicio. 4. a separação entre tipos na assinatura do método é com ";". O 4 é a única novidade. Segue um exemplo: procedimento calcular_soma_produto(a, b: inteiro; var soma, produto: inteiro) inicio soma <- a + b produto <- a * b fimProcedimento Adendo: um programa não deve* ter comentários. Ele deve está tão bem escrito, que não se fará necessário. Adendo 2: a medida que vai escrevendo um código, já vai testando. Assim os problemas tendem a está naquilo que está fazendo no momento. Exemplo: algoritmo "Exemplo_Parametros_Por_Referencia" procedimento calcular_soma_produto(a, b: inteiro, var soma, produto: inteiro) inicio fimProcedimento inicio fimAlgoritmo Além de ter visto logo o erro da falta das " lá no topo (errinho bobo), já identificaria que existe um erro na linha 3. Que foi justamente a falta do ";". Faria testes e testes... pesquisaria na internet etc. Daí vai dando continuidade. Claro que poderia também fazer de uma forma que faça rodar, como por exemplo deixar tudo com o var, até que entendesse/descobrisse como fazer... ou mesmo saber seria possível. Em síntese, o algoritmo sempre deve está "compilável"*. A única preocupação deve ficar na lógica, não na sintaxe. * o VisualG não compila código, ele apenas vai interpretando linha a linha em tempo de execução.

Com apenas essas informações fica mei difícil tentar ajudar... Dá uma arrumada na estrutura do teu código. Remove esse excesso de linhas em branco e faz a indentação. Após, posta o código completo e em qual parte está com dúvidas. Sobre especificamente a "área de lazer".. Basicamente você vai encontrar os dados do hóspede pelo nome, e vai somar o valor do item lá no campo que tem o "valor total das despesas do hotel", que consta na parte 2. Provavelmente algo como: valorgasto[indiceHospede] = valorgasto[indiceHospede] + valorDoItem

Mais uma pergunta retórica? Funções e procedimentos são basicamente a mesma coisa. Em algumas linguagens sequer tem essa diferenciação... são até apenas chamadas de "métodos". Apenas o que muda é que funções retornam valores nelas mesmas. Já os procedimentos seriam funções que não tem retorno neles mesmos. Um procedimento seria análogo a algo assim: funcao minhaFuncao() : VAZIO inicio fimFuncao Saca? "É" uma função que não tem retorno! Já utilizar por valor ou por referência seria só uma questão de necessidade do contexto do algoritmo. Eu suponho que seja muito mais comum as funções/procedimentos utilizarem por valor, já que é mais natural não precisar que o valor do que foi passado seja modificado ou que não precisa retornar algo de dentro da função. Um exemplo utilização de uso de por referência... imagine que precisa de um método que retorne dois valores. Funções só retornam um valor (e o VisualG não aceita vetor como retorno), e agora? Uma forma seria utilizar dois parâmetros por referência... . (Outra forma seria de algum jeito concatenar os valores numa cadeia só e depois separar fora da função etc. Vai da "robustez" ou "limitações" da linguagem... e também dos "padrões de projetos" e "boas práticas".) Por aí vai.

Reforçando: já comece a procurar dar nomenclaturas mais semânticas. Isso ajuda até evitar se cansar. Acredite!. Tipo: "para que serve a mesmo?" ou "qual a variável que está armazenando a quantidade de alunos?". Que tal: qtdAlunos? Veja como as expressões ficam mais autoexplicativas: enquanto (cont <= qtdAlunos) faca Nem precisa do restante do código para inferir para que serve... Você fez um algoritmo e não entendeu o que fez ou está analisando código de outra fonte? Mas vamos lá: A possível lógica aplicada seria que, a cada nova nota lida, verifica se essa nota é maior que a maior nota, ou seja, se for, essa nota atual seria a nova nota maior... Certo? Daí, quando essa condição for verdadeira, utiliza de uma variável auxiliar para copiar a tal nota e, como eventualmente quer o nome de quem tem a maior nota, também copia o nome... já que no contexto do algoritmo, estão relacionados. Por exemplo, se quiser apenas o nome do aluno com a melhor nota, sem precisar da informação do valor da nota dele, utilizaria apenas a variável melhorAluno... Por aí vai. A solução sempre vai depende da necessidade. O programa deve mostrar a nota e o nome do melhor aluno pois ao terminar de ler as notas (após o laço de repetição), vai está mostrando esses dados que foram obtidos. Dica: vá pressionando F8 e acompanhando linha a linha. Veja no canto deito os valores da variáveis a vá entendendo o fluxo natural dos programas. O VisualG vai lendo da esquerda para direita, de cima para baixo (mas vai mostrando uma linha completa por vez). Quando chega num se, e a condição é verdadeira, o código "entra no se", caso contrário, o código pula... por isso que também o se é chamado de "desvio condicional", pois faz o código sair do tal fluxo natural. O laço de repetição é semelhante... só que a condição faz repetir ou não o código. Vá testando que vai assimilando...

@Eli Almeidaa, você fez perguntas retóricas... é basicamente isso que você disse. Segue uma síntese:: 1. se uma variável local tiver a mesma nomenclatura de uma variável local, a função só pode acessar a mais próxima, ou seja, a local; No VisualG não tem como acessar a variável global de mesmo nome. Em algumas linguagens é possível; (Tem, por exemplo, o comando "this.", antes da variável, que diferenciaria indicando que quer a local.) 2. o var serve para ver lances que geraram dúvid... para fazer que as alterações nas variáveis locais sejam repassadas para as variáveis que foram passadas no respectivo parâmetro (sejam globais ou não... poderia ser de uma outra função), ou seja, a variável local seria uma 'referência" para variável que foi passada no parâmetro; No VisualG, ao terminar a função, o programa repassa o valor da local para a variável passada... Meio que trabalha separadamente. Em outras linguagem, creio que seja uma referência direta... (apontam para a mesma posição de memória... não sei dizer.). Na prática, o resultado final é o mesmo... mas tecnicamente o funcionamento é diferente. Qualquer coisa dá uma pesquisada sobre "ponteiros", algo bastante forte no C (que não manjo muita coisa); 3. como visto, o uso do var não tem relação com variáveis ter o mesmo nome. São coisas distintas. A relação é com a correspondência da variável passada ao chamar a função e a variável local lá do parâmetro. Se a local chamar t1 e passar t2 nela, vai altera no fim a t2 mesmo... 4. a questão de NÃO usar variáveis globais dentro de funções estaria relacionada a boas práticas. A recomendação geral é evitar usar mesmo e receber por parâmetro, mesmo que queira alterar (usando var). A questão também do parâmetro é que a função fica "desaclopada", ou seja, se eventualmente mudar o nome da variável global, não vai precisar mexer na função. A ideia é que as funções sejam livres... sequer precisam saber os nomes das variáveis que vão usar ao chamar a função (a única coisa relacionada é o "tipo de dado", que tem que ser compatíveis entre si). 5. resumidamente: a primeira função seria mais elegante que a segunda. Mas vai do contexto também. Está ligado à questão de "padrões de projetos", ou seja, as regras de implementações impostas, por exemplo, pelo professor ou pelo cliente quer o algoritmo. 6. No VisualG dá para "debugar" . Vai pressionando F8 e vendo os valores das variáveis no lado direito do programa. Tem também o conceito de bleakpoint e timer. 7. pode definir o var para individualmente. Como está usando "," para separar, vai todo o conjunto. Caso necessário, declara as variáveis separadamente, utilizando var ou não nas que desejar.

@Caiomqc, além dessa questão importantíssima sobre a escolha das nomenclaturas das variáveis, seria preciso definir melhor o escopo do problema. Sobre: "Como declarar uma condição igual para 3 variáveis diferentes?". A resposta depende... mas de um modo geral seria "declarar uma condição para cada variável", mesmo que eventualmente sejam condições iguais... ou buscar outra solução, como utilizar a mesma variável num loop. Ou utilizar um vetor e utilizar um loop para verificar as posições dele... ec Em relação à soma... é só ir somando após ter verificado. Algo como: somaPositivos <- somaPostivos + num1 somaPositivos <- somaPostivos + num2 Etc

Perfeito. O detalhe está aqui: Ou seja: só precisa inicializar uma vez... no início do programa. Algo como: funcao inicio() { inicializarQuartos() faca { escreva("\n Digite \n 1 – Cadastrar Hospedes \n 2 – Exibir Hospedes Cadastrados\n 3 – Exibir Quartos\n 4 – Atribuir Hospede a um quarto\n 5 – Reservar Área de Lazer\n 6 – Calcular Total a Pagar\n 0 – Sair\n ") leia(opcao) escolha (opcao) { caso 1: A função deve se limitar ao seu escopo, ou seja, a função exibir deve servir apenas para exibir... Zerar os quartos é algo externo.

Sim.. seria uma forma interessante. Podem, se quiser, utilizar o mesma nomenclatura... pois as variáveis da função ou procedimento são locais. Já as variáveis do programa principal são ditas como globais, como são de escopos diferentes, o VisualG permite "duplicar" os nomes... Veja: São 4 variáveis distintas. Sugiro pesquisar sobre: - variáveis globais x variáveis locais; - escopo - passagem de parâmetro por valor x parâmetro por referência Adendo: para testar linha a linha do código, pode ir pressionando F8.