Moderador: Moderadores
Código: Selecionar todos
function achanome
priv a=.t.
if fornec->(dbseek(ncdforn))
@2,20 say fornec->cnmforn
else
@2,20 say "Não Localizado!"
endi
retu aAí sou obrigado a discordar. Se você correr atrás na Internet e ver fontes de programas (realmente) bem feitos, você vai observar que ninguém segue o que você diz. Basta testar o que precisa ser testado e pronto. O que vier depois do ENDIF será executado de qualquer maneira. Um ELSE desnecessário deveria ser sempre suprimido. Fico com o exemplo do ABeltrani, que ficou mais enxuto. Embora nele também haja um problema, não por culpa dele. O que mata realmente a manutenção é você ter coordenadas de tela em várias funções. Mude uma coisinha de lugar e pronto, o cheiro de enxofre toma conta do ar. Vira um verdadeiro inferno, dependendo da quantidade de @...SAY que você tiver. Hoje, quando eu mudo um campo GET de posição, altero apenas em um único lugar. Isso sim é um exemplo de coisa que faz diferença. Um ELSE a mais pode fazer o efeito inverso, tornando a leitura do código muito pior.Eolo escreveu:Eu não gosto de fazer do jeito que vc sugeriu, prefiro deixar bem definidos os limites do IF e do ELSE, separando claramente o que vai em cada caso. Do jeito que vc sugeriu, o ELSE tá "mascarado", parece que não existe... E isso pode fazer a coisa ficar complicada na hora da manutenção, principalmente se forem muitas linhas de código em cada opção...
Muitas lógicas de programação se tornam extremamente simplificadas justamente usando RETURNs em vários pontos de uma função, principalmente se ela for um pouco mais extensa. Agora, convenhamos, uma função simples com 500 linhas (é um exemplo fictício?) é uma função que certamente tem um grave problema de lógica. E havendo problema desse tipo, não será um RETURN a mais que vai piorar as coisas. A manutenção, num caso desses, sempre será mais difícil.Uma outra coisa (que me escapou): embora eu tenha sugerido a função com 2 RETURNs, eu nunca faço isso. É só UM e sempre no fim da função, pelo mesmo motivo: um RETU "perdido" no meio de 500 linhas pode complicar a vida da gente.
Código: Selecionar todos
function SayFornec(nCodFor)
@ 2,20 say Fornec->(if(dbSeek(nCodFor), cnmforn, "Erro!"))
return Fornec->(Found())Código: Selecionar todos
#define _LIN_FORNEC_NOME 2
function SayFornec(nCodFor)
@ _LIN_FORNEC_NOME,20 say Fornec->(if(dbSeek(nCodFor), cnmforn, "Erro!"))
return Fornec->(Found())Bão, se meus programas são (realmente) mal feitos MAS funcionam como deveriam (de acordo com meus clientes) e se eu fico absolutamente confortável navegando neles na hora da manutenção, pra que eu vou fazer diferente? Vou complicar a minha vida só pra satisfazer a comunidade científica mundial? Esquece...Se você correr atrás na Internet e ver fontes de programas (realmente) bem feitos, você vai observar que ninguém segue o que você diz.
Cara, não ponha palavras na minha escrita. E tente se abstrair (e relaxar).. Agora, convenhamos, uma função simples com 500 linhas (é um exemplo fictício?) é uma função que certamente tem um grave problema de lógica
))Beltrani,testar o que precisa ser testado e pronto. O que vier depois do ENDIF será executado de qualquer maneira. Um ELSE desnecessário deveria ser sempre suprimido. Fico com
Código: Selecionar todos
função procuravenda(venda)
priv achou, abc
use vendas new
seek venda
achou=found()
use clientes new
seek vendas->codcli
if achou
?clientes->codcli+" "+clientes->Nome+" "+clientes->cpf
abc=.t.
* sele vendas
* use
* Sele clientes
* Use
* return abc
else
?"Venda não existe"
abc=.f.
* sele vendas
* use
* sele clientes
* use
* return abc
endi
sele vendas
use
sele clientes
use
return abcDesculpe, Eolo. Mas você entendeu o meu post de maneira totalmente errada. Eu não quis levar-lhe ofensa, como você parece ter entendido. Não quis dizer que o seu código é mal feito. Leia direito. Obviamente eu quis dizer que eu acho que o seu pensamento está errado e o meu está certo. Apenas discordei. Fiz mal?Eolo escreveu:Bão, se meus programas são (realmente) mal feitos MAS funcionam como deveriam (de acordo com meus clientes) e se eu fico absolutamente confortável navegando neles na hora da manutenção, pra que eu vou fazer diferente? Vou complicar a minha vida só pra satisfazer a comunidade científica mundial? Esquece...
Acho que deveria. Mas acho também que ninguém disse que você é obrigado a qualquer coisa que seja.eu não sou obrigado a abandonar o ELSE.
O comando ELSE é uma simples decorrência do IF. Se fosse para haver um teste booleano como condição (TRUE) para a execução de um bloco de código, sua contra-partida lógica (FALSE) também deveria existir. Mas o (opcional) ELSE deveria ser usado apenas no caso de uma real necessidade. O comando ELSE tem seu lugar. Mas não é em todo lugar onde há um IF. Ou seja, a existência de um IF não deve pressupor a criação de um ELSE a ele agregado. Seria um exagero. Totalmente descabido.Aliás, agora fiquei com a purga atrás da orêia: se não é pra usar o ELSE, por que inventaram ele?
Mas é claro que o meu jeito é o mais certo e é o único a seguir. Se eu achasse errado e ainda assim expusesse como certo, seria um estúpido. Seu erro foi querer acreditar que eu estava impondo meus conceitos. Errado! Eu estava expondo. É bem diferente. Mas você quis levar pro lado errado.Cara, no seu post fica implícito que o SEU jeito é o melhor e único a seguir. E não é bem assim...
Eu me referia apenas às informações de coordenadas do @...SAY. É algo que, como eu disse, pode dificultar a manutenção em telas com muitos ítens, principalmente quando há diversas funções espalhadas no fonte que utilizam essas coordenadas. No seu exemplo você fez certo. Apenas informou as coordenadas. Até porque, o tópico nem se referia a isso. Nós extrapolamos o objetivo da thread.ABeltrani escreveu:Vc citou um problema no meu exemplo ! Agora tô curioso ! Qual seria ?
Note, por favor, que você comentou sobre uma função com 500 linhas. Note também que eu botei parênteses numa pergunta (leia de novo, se precisar), justamente porque eu achei que você estava apenas usando um exemplo fictício. Eu não disse que você tem função de 500 linhas. Mas embora não tenha, o que eu disse pode ter serventia, pois pode apostar que alguém no fórum tem funções até maiores. Lendo meu post esse alguém saberá qual é minha opinião a respeito. Acho que ela vale alguma coisa.Eolo escreveu:b) segundo, eu só dei um exemplo. De onde vc tirou a idéia de que alguma função minha tem 500 linhas e tem um "grave problema de lógica"? Nessa vc viajou 10, bateu em Plutão!. Agora, convenhamos, uma função simples com 500 linhas (é um exemplo fictício?) é uma função que certamente tem um grave problema de lógica
Bisteca escreveu:Caros amigos. Estou montando um cadastro de contas à pagar e preciso fazer o seguinte:
@ 1,1 say "digite o numero do titulo: " get ntit
@ 2,1 say "digite o código do fornecedor: " get ncdforn
@ 3,1 say "digite o código do centro de custo: " get ncdcent
read
Ai preciso pesquisar no cadastro de fornecedor o código digitado. Se foi encontrado, preencho com o nome. Se não foi encontrado, que voltar no get do fonecedor.
Depois a mesma coisa para o centro de custo.
Só que como o read esta no fim não sei como fazer isso, não quero usar um read para cada get, pois assim não conseguiria voltar nos campos usando as setas.
Alguém poderia me ajudar?
Obrigado
