PC Toledo

oi pessoal, boa madrugada!

os comandos EXIT, LOOP, RETURN, possuem alguma função que os substitua?

porque estes não podem ser colocados dentro de CODEBLOCKS, funções IF( ) e em outros casos.
abuso de CODEBLOCKS e IFs( ) e esta restrição dos comandos me limita quando tenho muitas destas funções uma dentro das outras.

inclusive li em alguns livros, que embora o PC seja hoje a jato, na época que era à manivela, toda vez que pudesse ser implementado uma IF( ) no lugar de um IF;ELSE;ENDIF ou IF;ENDIF, otimizava-se o processamento. sempre me pareceu mais produtivo e flexível trocar...
é claro... aqui apenas um micro-trecho de código de 11 linhas em uma... mas isso nos meus PRGs é massivo.
caso exista funções substitutas para os dito-cujos (perdoem minha ignorância...) vai reduzir + de 25% de linhas dos meus PRGs, porque mantenho ainda algumas estruturas na forma comum por causa dos EXIT, LOOP, RETU...
é importante para mim, gosto de funções que simplificam e evitam muitas linhas de códigos na tela, e se posso transformar 100 linhas em 25, tô dentro!
eu gostaria também (opa, já to escrevendo muitas linhas...) de sugestões em termos de uso inteligente de estruturas que poupam código.

Valeu!

Os comandos nativos, como os que citou, não são macros ou comandos criados artificialmente. São comandos mesmo.
Sua idéia de enxugar código trocando comandos por funções não vai funcionar de fato. Explico: o intuito do comando é justamente simplicar o uso de funções. Muitas funções têm uma lista de parâmetros enorme. Um comando não só simplifica, como torna o código mais fácil de manter. Veja a tradução do comando GET no header STD.CH. Aliás, melhor ainda: veja o PPO (para obtê-lo use o switch \p ao compilar) de um fonte seu em que tenha usado ao menos um GET. Já imaginou substituir este comando pela sua função? Você teria justamente o efeito inverso do desejado.

Acho que a única coisa realmente boa do Clipper é justamente o recurso de criação de comandos, pois isso facilita a codificação e torna o código muito mais legível. O código exemplo que posto, por exemplo, é uma balbúrdia. O que antes era legível se tornou macarrônico, horrível de ler. Note a quantidade de parênteses. Isso não é simplificar. É bem o contrário. Você precisa tornar o código MAIS legível. Por isso, não se incomode com a quantidade de linhas. Até porque, você nunca conseguirá reduzir na proporção de 100 para 25. A não ser que queira colocar seu fonte na condição de "aberração".

Conselho de amigo com 20 anos de experiência: não se tranquilize com o fato de hoje você conseguir entender o que fez. Preocupe-se com a possibilidade de não entender o seu próprio fonte daqui um ano ou dois. Documente o fonte e mantenha-o limpo, legível, de forma que qualquer programador possa lê-lo e entendê-lo.

hahahahahaha, xô macarrônica aberração de código!

tem razão! já fiquei sem entender o qui fiz algumas vezes embora estivesse funcional.
cheguei até em alguns casos, criar um diário-de-bordo num TXT para entender a treta toda.
seria correto dizer então que os comandos nativos seriam a parte infinésimal (como um atómo) da programação?
aproveitando o gancho, o que são entryPoints que postou em outro thread?

mais uma pra caxola!!! obrigado Sr Maligno!

em tempo: como desconhecia o DispOutAT(), dbgShadow() e mais alguma que vi por aqui, o meu principal interesse nas funcões não-documentadas é poder inserí-las em casos que possam substituir um conjunto de instruções redudantes, reutilizando e teletransportando blocos-de-código de uma parte à outro do programa, armazenar em DBF para posterior re-utilizacão em outro app Clipper, etc.
como não se pode utilizar o que está invisível ou é desconhecido.... a __Quit(), a DispOutAT() e outros me facilitaram coisas que antes me esquentava a cabeça em como implementar.
embora ainda engantinhando na linguagem, meu conhecimento técnico é pouco mas às idéias fervilham!!!
como disse: o que não serve à alguem mais ou parece tolo, pode ser exatamente o que o outro tá precisando na justa proporção. valeu!

Olá!

Creio que a solução para a tua questão seja a função BREAK(). Mas, o conselho dado pelo Maligno é mais real do que possa parecer. Fica muito mais difícil ler e entender um código assim. Realmente, até o autor, após algum tempo, terá dificuldade. Imagine outra pessoa tendo que dar manutenção nesse código.

já fiquei sem entender o qui fiz algumas vezes embora estivesse funcional.

Sim, isso é uma "pegadinha" que dá auto-confiança. A coisa funciona do jeito que deve funcionar e lendo na hora você vê tudo certo. Mas um ano depois, ao ler essa parte novamente, nem você não consegue entender porque não documentou e não consegue ler porque a leitura é realmente mais difícil. Logo, acaba demorando um tempão pra saber o que fez.

o que são entryPoints que postou em outro thread?

Genericamente, são endereços de memória. Se código, servem para jumps (saltos) diretos. Não em Clipper, mas em outras linguagens pode ser vantajoso substituir uma função de sistema por outra. Ao final, salta-se para a antiga usando seu entryPoint. Mas há outras aplicações. E se representarem dados, são endereços úteis para acessar informações de tabelas ou conteúdos de variáveis de sistema, normalmente ocultos.

puxa Alexandre, embora tivesse lido sobre esta função em algum lugar, não conseguia fazer associação como solução.
será de imediato muitíssimo útil.
obrigado!