Página 1 de 2

Enviado: 28 Dez 2007 16:45
por Eolo
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...

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 achanome 
priv a=.t.
if fornec->(dbseek(ncdforn)) 
  @2,20 say fornec->cnmforn 
else
  @2,20 say "Não Localizado!" 
endi
retu a

Enviado: 03 Jan 2008 00:13
por Maligno
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...
Aí 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.
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.
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.

Com relação ao código do colega, apenas pra dar uma simplificada:

Código: Selecionar todos

function SayFornec(nCodFor)
@ 2,20 say Fornec->(if(dbSeek(nCodFor), cnmforn, "Erro!"))
return Fornec->(Found())
Fica mais simples, mas ainda tem a localização do ponto de impressão. O ideal seria abstrair isso. Há um modo que é bastante trabalhoso, mas resolve essa questão muito bem. Eu nunca defino linha num campo GET. Apenas coluna e num só lugar. Facilita e é como eu uso hoje. Mas isso demanda descrever uma série de sub-sistemas. Não daria muito certo. Mas há uma forma que ajuda a simplificar isso, através do uso de constantes. Alguns #defines no início do fonte já resolveriam. Algo mais ou menos assim:

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())
Isso já ajudou um pouco. Ao menos o número da linha foi suprimido. O chato é que, dependendo do tamanho da coisa, se for incluir as colunas nesse esquema, vai ficar um amontoado gigantesco de #defines. Mas o caminho é mais ou menos esse: abstrair.

Enviado: 03 Jan 2008 10:47
por Eolo
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.
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...

Não estou em nenhuma competição, cara.

Fazendo uma analogia: se o Fulano e o Sicrano NÃO sabem usar CRASE perfeitamente, com base na língua dita culta, então eles ficam proibidos de se comunicar aqui no Fórum, porque ninguém vai entendê-los? Não é bem assim, certo? Então, eu não sou obrigado a abandonar o ELSE.

Aliás, agora fiquei com a purga atrás da orêia: se não é pra usar o ELSE, por que inventaram ele?! :-)


Cara, no seu post fica implícito que o SEU jeito é o melhor e único a seguir. E não é bem assim... (fazendo outra analogia) Qual vc considera o inglês "certo"? O da Inglaterra ou o da Escócia? Ou é o dos Estados Unidos? Ou não é nenhum deles, o da Austrália ganha longe? Ou o que? O da África do Sul tem que ser banido da face da Terra?

Enviado: 03 Jan 2008 11:18
por ABeltrani
Bom dia Maligno ! Blz ?

Vc citou um problema no meu exemplo ! Agora tô curioso ! Qual seria ?

Enviado: 03 Jan 2008 11:20
por Eolo
. 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
Cara, não ponha palavras na minha escrita. E tente se abstrair (e relaxar).

a) eu não usei a palavra 'simples' no meu post. De onde você tirou ela? Nessa vc viajou, cara! Talvez ressaca do fim de ano?... Hum...

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!

Mas não se preocupe. Não fiquei magoado. Sei que é só questão de opinião. Até eu, mesmo não usando o ELSE, posso ter as minhas. :-)))

Enviado: 03 Jan 2008 12:18
por Eolo
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
Beltrani,

A seguir, um exemplo (simples, beeeem resumido) do porque que eu não uso RETURN no meio de funções: no exemplo (hipotético) abaixo, eu abro 2 arquivos e, não importa o que acontecer no IF/ELSE/ENDI, eu tenho que fechá-los na seqüência.

Então, se eu colocar um RETURN no meio da função, vou ter linhas duplicadas (veja as linhas com "*"). Prefiro, ao contrário, colocá-las em evidência no final da função. Eu elimino as duplicidades e, melhor, me asseguro que os DBF sejam fechados antes do término da função.

Mas, veja bem: esta é a MINHA maneira de trabalhar. Pra mim funciona, pra vc pode não funcionar. Você decide aí qual a melhor maneira pra você. Há dezenas de maneiras diferentes de fazer esta mesma coisa, com resultados muito semelhantes. Eu só estou dando uma sugestão :-)

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 abc

Enviado: 03 Jan 2008 13:17
por sygecom
Eu uso o ELSE e não vejo problema algum em usar, alias se ninguem mais usa vou entender que ela foi feita exclusivamente para min !!! nossa que emoção !!! hehehehehe

Enviado: 03 Jan 2008 13:24
por Maligno
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...
Desculpe, 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?

Note que há uma "cultura" instalada nesse meio, firmada por anos e anos de experiência dos melhores desenvolvedores, que elaboraram inúmeras técnicas e metodologias voltadas para a maximização tanto da qualidade do software quanto da manutenibilidade. Foi essa cultura, cuja lógica eu aceito (no todo ou em parte) que quis comentar. Nem comento essa sua idéia de "competição".

Se a forma que você faz lhe traz satisfação, apesar de discordar da sua idéia, não serei eu a condená-lo. Tampouco tentar impor coisa alguma. Meu lema é "viva e deixe viver".

Não tome isso como arrogância da minha parte, mas eu pretendia compartilhar um pouco dos mais de 18 anos de experiência que tenho, não como um simples montador de programas, mas como desenvolvedor de software que sempre esteve (e está) receptivo e pronto para, humildemente, aprender coisas novas e a mudar antigos conceitos. É sempre tempo de aprender. Eu não sou perfeito.
eu não sou obrigado a abandonar o ELSE.
Acho que deveria. Mas acho também que ninguém disse que você é obrigado a qualquer coisa que seja.
Aliás, agora fiquei com a purga atrás da orêia: se não é pra usar o ELSE, por que inventaram ele?
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, o mesmo vale para o RETURN único, apenas no fim da função. Abrir não de um instrumento facilitador de lógica apenas para tê-lo único no final da função é, a meu ver, um conceito errôneo que desvirtua a finalidade do comando. Claro que há casos em que, simplesmente acontece da lógica ficar melhor assim. Mas nem sempre. Se o código for bem feito, mesmo com vários RETURNs espalhados, a manutenção não fica prejudicada. Pelo contrário.
Cara, no seu post fica implícito que o SEU jeito é o melhor e único a seguir. E não é bem assim...
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.



Se alguém me diz que estou errado em alguma coisa, numa crítica construtiva, a última coisa que eu deveria fazer era bater o pé, simplesmente dizendo que o que eu faço funciona. Claro que, se realmente acho que estou certo, exponho minhas razões, firmando minha posição, civilizadamente, com base em argumentos válidos. Eu sempre procuro ser esperto. Procuro analisar o que foi dito e tento aproveitar alguma coisa. Consultoria grátis! Vou desperdiçar? Claro que não. Só jogo pra ganhar. Tento sempre somar algo a minha bagagem.

Sim, este meu último parágrafo foi uma crítica a sua reação, que achei totalmente desproporcional.

Enviado: 03 Jan 2008 13:25
por Maligno
ABeltrani escreveu:Vc citou um problema no meu exemplo ! Agora tô curioso ! Qual seria ?
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. :)

Enviado: 03 Jan 2008 13:26
por Maligno
Eolo escreveu:
. 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
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!
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.

Enviado: 03 Jan 2008 13:54
por Eolo
Maligno,

Po, vc me perdoa? Eu sou mesmo um anta. Nem percebi que vc só quis me ajudar. Vc, que sempre tem as respostas (vc é parente do Chuck Norris?). Eu sou mesmo uma besta. Cara, me perdoa?

Aliás, vou tomar providências, já!:
. eliminar todos os ELSE dos meus programas!
. se tiver alguma função com mais de 500 linhas, vou deletar todas!
. incluir RETURNs em tudo o que é canto!
. etc.

Cara, valeu! Obrigado pelas dicas.

Me sinto muito melhor agora.


PS. Desculpe, não resisti. HHJAUIHUAHUAHUAHUHAUHAUHUASS

Re: Dúvidas com Get e Read

Enviado: 03 Jan 2008 14:06
por ederxc
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

Brother Bisteca, voce conseguil resolver em meio da guerra do "cabeza dura do Eolo "e o mestre do teclado padrão americado ,Maligno ??

Se sim maravilha , se não posta ae que ATÉ EU , posso lhe ajudar ...




Não resisti [02] auhauhauahUHhuHUuhHUhuHUhuHUhu

Enviado: 03 Jan 2008 14:11
por Eolo
Eder,
QUEM é o "Brother"?
QUEM é o "Cabeza Dura"?
QUEM é o "Mestre do teclado padrão americano"?
Explica? Porque só vc tá se divertindo...

Enviado: 03 Jan 2008 14:13
por Eolo
Ah, Eder, então vc editou o seu post...
O que foi, não teve coragem no primeiro post? Teve que editar?

Enviado: 03 Jan 2008 14:16
por Eolo
"cabeza dura do Eolo "?

Tá. Cara, vc é empregado (tipo ganha salário, 13o., férias etc) ou vive por conta própria? O seu patrão (ou cliente) tem PCs tudo primeira linha, Dual Core Ultimate Chuck Norris ou tem alguns PC Pentium 3 com Win98 rodando?