PC Toledo

É muito bom acostumar com esse padrão de programação.
Mas é importante que não fique limitado aos erros de compilação.

Exemplo: Essa rotina não passa no padrão /w3.
Primeiro porque as variáveis não estão definidas em cada rotina.
Segundo porque a função ConteudoOk() usa uma variável que não conhece.
Mas se acrescentar MEMVAR para a variável mvar, já passa na compilação com /w3.

A intenção do /w3 não é apenas essa.
O certo é que cada rotina conheça as variáveis que usa.
Então, o mais correto seria alterar dois pontos:
Valid ConteudoOk(mVar)
Function ConteudoOk(mVar)

Obs. Poderia ser indicado direto no valid, mas este é só um exemplo do que seria o padrão /w3

Mas mesmo assim... qual vantagem?
Antes de alterar, a rotina ConteudoOk() é totalmente dependente da variável existir na rotina que a chama. Não se pode nem mexer no nome da variável, e se for usada por outra rotina, é obrigatório usar o mesmo nome de variável.
Após alterar, ConteudoOk() se tornou uma função independente, e pode tranquilamente ser modificada, ou usada em qualquer rotina, seja qual for a variável.

É isso que se deve tomar cuidado: não confundir padrão /w3 com apenas evitar erros ao compilar com /w3.

Acontece de vez em quando de digitar errado o nome de uma variável, e só vamos descobrir quando está rodando no cliente.
Usando o padrão /w3 isso já não acontece, porque o compilador vai reclamar das variáveis usadas que não foram declaradas.

Por isso aconselho: se puder usar, use o padrão /w3.
Se tem um sistema grande, vai ser um grande trabalho fazer o ajuste, podendo causar até erros aonde já funcionava.
Mas pode já adotar o padrão pra novas rotinas.

Aqu fiz o contrário do que indicaram:
Coloquei no fonte velho #pragma /w0
E fixei o compilador com /w3 /es2

Com isso, tudo que é novo já é feito desse modo. E os programas antigos, vou alterando um por vez.

Com relação a isto realmente é uma ótima prática

Agora na alteração me deparei com um problema... veja o final do código
o compilador da a mensagem: Warning W0028 Unreachable code

devido o break antes do return tipo não vai ler a linha debaixo... porém se eu tiro o return da outra mensagem...
E agora como resolver?

Acho que o problema está na forma de uso do Break.

Quando você usa o Break sem direcionamento, ele retorna para a linha imediatamente abaixo do End Sequence de onde ele ele foi chamado numa função ou bloco entre: Begin Sequence / End Sequence.

Quando você usa o Break com direcionamento, por exemplo: Break NomeDaFuncao(), ele retorna para a função que foi direcionado sem retorno para onde ele foi chamado, ou seja, a execução dá sequência de onde ele foi direcionado.

Não é possível receber o valor de Variável ou Objeto através de um Break, tal como um Return.

Acho que é isso.

O erro "Warning W0028 Unreachable code" significa que NADA será executado depois de BREAK, e por isso aquela continuação do fonte não tem sentido.

Mas pera lá....
BREAK não é usado dentro de um BEGIN-END ? Algo como o EXIT do DO WHILE?

Não. Break tem uma amplitude muito maior que isso. Exemplo:

Fiz um teste usando esse mesmo fonte.
Se colocar assim, dá o erro que foi mencionado.
Até tem sentido, porque se o BREAK é para exceções, faltaria a saída normal.
A saída, num caso destes, seria enganar o compilador:
Aliás... se sempre sai com BREAK, tanto faz ter ou não, vai sair de qualquer jeito.
O uso é que está estranho mesmo, É como um IF sem ELSE, ou um ELSE sem IF.

Um fonte assim ficaria confuso, por exemplo se alterar área de uso, e outras coisas.

Mas independente disso, se em consulta() sempre sai com break, ficou sem opção de escolha para com BREAK/sem BREAK.
Talvez melhor colocar a condição no fonte anterior.
Teria que analisar os fontes em conjunto.
Talvez usar o retorno de consulta()
Parece que o compilador fez bem em não aceitar o BREAK dessa forma.
Tem algo esquisito aí... rs

Eu uso assim, e vai tranquilo:
Abs.

Vlw pessoal vou dar uma olhada

A vantagem do -w3 -es2 é mostrar aonde pode ter coisa errada.
Não se trata apenas de compilar ou não, ou de apenas tratar o erro, mas de confirmar se da forma que foi feito está correta.

Exemplo de um erro parecido:
Aí também acusaria erro, porque o EXIT sai fora do DO WHILE, então SKIP em seguida é inútil.
Mas se SKIP é inútil, o DO WHILE também...
Então não se trata apenas de eliminar o erro do SKIP, mas de revisar o fonte, pra ver se era isso mesmo.
o BREAK indicado seria uma situação parecida com essa.
Se compilar com -w1 -es1, não acusa erro, mas o fonte continua esquisito.... rs

Se alterar para:
Isso elimina o erro de compilação, mas de qualquer forma o fonte continua esquisito.

Essas são algumas checagens extras interessantes ao usar -w3 -es2.
É algo como ter um programador experiente te mostrando as coisas "esquisitas", que podem ser problema.
Às vezes é só resolver a mensgem de erro, mas às vezes é bom revisar o que acontece no fonte.

Isso num fonte pequeno tá bem visível, mas num fonte grande só mesmo com a ajuda do compilador.
(ou no caso do BREAK, que usa até fontes/rotinas diferentes).