paulo1205
(usa Ubuntu)
Enviado em 19/10/2016 - 16:08h
Eu sempre fico impressionado como alguém, ao escrever um programa simples mas que não funciona, quer logo colocar a culpa no compilador, em vez de olhar para o próprio programa primeiro.
Além de ter utilidade limitada, duplicando de forma piorada aquilo que se pode fazer com o comando
seq, o programa indicado na primeira postagem possui diversos exemplos de erros e de práticas de programação ruins.
Exemplos de erros:
- Declaração inadequada da função
main -- deveria ser “
int main(void)”, já que o programa não recebe argumentos pela linha de comando (se os recebesse, deveria ser “
int main(int argc, char **argv)” ou equivalente).
- Conversões de
scanf() incompatíveis com os tipos de dados das variáveis que devem receber os valores lidos.
- Mesmo erro nas chamadas a
printf() e
fprinf() que imprimem o valor de
n1.
- Se as conversões de
scanf() estivessem correta, ainda haveria a chance de o laço de repetição nunca acabar. Se o valor finalmente atribuído a
n2 for igual ao maior valor possível para um dado do tipo
long int, então por definição a comparação “
n1<=n2” será sempre verdadeira.
Exemplos de hábitos ruins:
- Não se testam os valores de retorno das chamadas a
scanf(), de modo que
n1 e
n2 podem chegar com valores desconhecidos ao laço de repetição (e.g. se o usuário digitar uma letra em vez de um valor numérico).
- Se acontecer o problema mencionado acima, o restante da execução do programa fica imprevisível. Com sorte, o loop pode terminar sem executar nenhuma iteração (se
n1>
n2); com azar, pode nunca acabar (
n2==
LONG_MAX). Depender de sorte, em qualquer programa, é o fim da picada.
- Também não se testam os resultados das operações de escrita. De fato, é bem menos comum fazer isso mas, a rigor, também as operações de escrita deveriam ser verificadas quanto a possíveis erros, especialmente num programa que gera um arquivo como saída. Só não devem verificar se as operações de escrita foram bem sucedidas programas que não se importem de perder dados ou de entregar ao usuário algo diferente daquilo que ele pediu..
- A atribuição “
n1=n1” não chega a ser um erro, mas é inútil. Sendo inútil, deveria ser removida. A sintaxe do comando
for permite essa remoção.
- Contudo, se você quiser evitar o possível loop infinito, possivelmente não deve usar
for, mas talvez uma combinação de
if com
do-
while.
- Chamar
system() para uma operação trivial como limpar a tela é um tremendo desperdício. Se limpar a tela fosse absolutamente necessário para o programa, a funcionalidade deveria residir no programa, ainda que através de uma biblioteca padronizada, tal como Curses ou algum clone da ConIO.
- Chamar
system() também é um tremendo furo de segurança, ainda mais quando você não diz o caminho exato do comando a ser executado. Se o usuário possui algum script chamado
clear num diretório local que esteja presente no valor da variável de ambiente
PATH, esse script pode acabar sendo chamado, em vez do utilitário do sistema que você esperava que fosse chamado.
- 34,48% da extensão do programa (10 de 29 linhas contendo texto) são usadas com créditos e outras firulas. Acho que não precisa disso -- ainda mais no atual estado do programa.
