Além de ter utilidade limitada, duplicando de forma piorada aquilo que se pode fazer com o comando “seq“, esse programa possui diversos erros e práticas de programação ruins.
Exemplo 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)”.
- 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().
- Se a conversão de scanf() estivesse correta, ainda haveria a chance de o laço de repetição nunca acabar. Se o valor digitado for igual ao maior long int possível e esse valor for atribuído a n2, 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 pode chegar com valores desconhecidos ao laço de repetição (por exemplo, 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 (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 se 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 permite essa remoção.
- Contudo, se você quiser evitar o possível loop infinito, possivelmente não deve usar o comando 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 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.
Gostei da sua ideia!