Enviado: 10 Mar 2008 14:45
Isso deixa de fora qualquer alerta que o programador queira emitir, no caso de falha.gvc escreveu:@ 10,01 Say "Informe a UF: " get opc Pict "!!" valid ascan(aMenu1, opc) > 0
Página 3 de 3
Enviado: 11 Mar 2008 11:42
Bom dia turma !!
... questão de gosto né!! Vários caminhos que levam ao mesmo lugar. Se vc tem tempo vai por ali, senão por aquí.
Achei prático, fácil e rápido a rotina do gvc.
Lendo o livro Dominando o Clipper 5.2, achei interessante um trecho em que o autor diz que existe muitas lacunas de conhecimentos a serem preenchidas até mesmo para programadores experientes.
Isto avaliza as palavras do malígno quando diz que por conta do imediatismo, pulamos certas etapas do aprendizado.
Este é um vício difícil de erradicar.
Um abraço a todos !
Netavin
... questão de gosto né!! Vários caminhos que levam ao mesmo lugar. Se vc tem tempo vai por ali, senão por aquí.
Achei prático, fácil e rápido a rotina do gvc.
Lendo o livro Dominando o Clipper 5.2, achei interessante um trecho em que o autor diz que existe muitas lacunas de conhecimentos a serem preenchidas até mesmo para programadores experientes.
Isto avaliza as palavras do malígno quando diz que por conta do imediatismo, pulamos certas etapas do aprendizado.
Este é um vício difícil de erradicar.
Um abraço a todos !
Netavin
Enviado: 11 Mar 2008 13:33
Eu não faria como o GVC. Sistemas de informações normalmente utilizam as siglas dos Estados em vários pontos do programa. Se tivermos que fazer esse teste várias vezes, desperdiçamos espaço à toa. Descontamos aí o fato do colega GVC também ter feito um código de exemplo. Coisa simples, rápida e ficou isso aí. Mais uma vez, se alguém ver e tomar como a solução correta, vai atropelar os detalhes não tão óbvios. Meu exemplo, mais elaborado:
Mas ainda há uma alternativa. Haja vista que as siglas dos Estados tem a única finalidade de conferência, é válido também apenas utilizar uma só string:
Um pouco mais simples e até mais econômico no processamento, embora isso não conte muito. Mas fica também mais legível.
De qualquer forma que seja, sendo UFsList() uma função global, de biblioteca, tenho apenas um pouco de espaço alocado para uma lista constante. Economizo no tamanho do EXE e facilito a manutenção.
Na verdade não faço de nenhuma dessas formas. Meu VALID teria uma função externa para emitir um aviso qualquer para o usuário, sinalizando o erro. Aliás, sou de opinião de que se o usuário errou, ele deve ser avisado, seja da forma que for. Se o teste já ficar no VALID não tem jeito. Por isso não uso essa forma.
Mas como utilizo comandos customizados, não vou entrar nos detalhes, pra não embaralhar a didática. Apenas deixo no ar a idéia básica da unicidade das funções. Vale o ditado: "cada macaco no seu galho". Se misturar várias tarefas em funções de apoio, só se perde. Trabalha mais? Em um primeiro momento sim. Mas ganha-se muito mais lá na frente.
Aliás, pra quem tem tempo pra estudar, aconselho a leitura de um livro qualquer sobre Projeto Estruturado de Sistemas. Recomento o da dupla Meiler/Page-Jones. É o tipo de leitura esclarecedora e gratificante.
Código: Selecionar todos
cUF := Space(2)
@ 1,2 say "Estado:" get cUF picture "@A !!" valid AScan(UFsList(),cUF) > 0
read
function UFsList()
return {"XX","YY","ZZ",...}Código: Selecionar todos
cUF := Space(2)
@ 1,2 say "Estado:" get cUF picture "@A !!" valid cUF $ UFsList()
read
function UFsList()
return "XX,YY,ZZ,...De qualquer forma que seja, sendo UFsList() uma função global, de biblioteca, tenho apenas um pouco de espaço alocado para uma lista constante. Economizo no tamanho do EXE e facilito a manutenção.
Na verdade não faço de nenhuma dessas formas. Meu VALID teria uma função externa para emitir um aviso qualquer para o usuário, sinalizando o erro. Aliás, sou de opinião de que se o usuário errou, ele deve ser avisado, seja da forma que for. Se o teste já ficar no VALID não tem jeito. Por isso não uso essa forma.
Mas como utilizo comandos customizados, não vou entrar nos detalhes, pra não embaralhar a didática. Apenas deixo no ar a idéia básica da unicidade das funções. Vale o ditado: "cada macaco no seu galho". Se misturar várias tarefas em funções de apoio, só se perde. Trabalha mais? Em um primeiro momento sim. Mas ganha-se muito mais lá na frente.
Aliás, pra quem tem tempo pra estudar, aconselho a leitura de um livro qualquer sobre Projeto Estruturado de Sistemas. Recomento o da dupla Meiler/Page-Jones. É o tipo de leitura esclarecedora e gratificante.