É uma boa prática evitar avisos e avisos?

Geralmente, tenho trabalhado com avisos e avisos do PHP desativados, pois trabalho em muitos projetos em que já está em produção ao vivo. Agora, se eu ativar os avisos e avisos nesses sites de produção ao vivo, eles ficarão sobrecarregados.

Nos projetos em que trabalho em casa, no local, geralmente tento resolver TODAS as advertências e avisos. Às vezes, não há solução para não ter um aviso, então eu teria que lidar com o aviso até decidir desativá-los completamente.

No final, não sei se estou perdendo meu tempo tentando me livrar de todos os avisos e avisos, ou se estou realmente fazendo isso para o bem maior.

Daí a minha pergunta, é uma boa prática evitar completamente avisos e avisos, ou isso realmente não importa?

se eu ativar os avisos e avisos nesses sites de produção ao vivo, eles ficarão sobrecarregados.

Você sempre deve ter avisos ativados no nível mais alto em desenvolvimento, teste e controle de qualidade, mas não em produção. Na verdade, se é um aplicativo de dogfood, ou seja, um aplicativo que você usa, também deve ativá-los na produção.

Basicamente: ative-os nos casos em que a pessoa que os vê está em posição de fazer algo sobre eles (o desenvolvedor no desenvolvimento e nos testes pode corrigi-los, o testador no controle de qualidade pode registrar um erro e, se o desenvolvedor estiver também o usuário, ele também pode consertá-lo na produção), mas não ative-o quando a pessoa que vê não puder fazer nada sobre ele (um usuário em produção, que nem sabe programar).

Idealmente, você também deve ativar o tratamento de avisos como erros, mas isso só funciona se não houver nenhum ;-) Mas lembre-se disso como um objetivo! Se for possível ativar / desativar isso por arquivo, ative-o para todos os novos arquivos e ative-o para todos os arquivos sem aviso e nunca desligue-o novamente depois de ligado.

Então, o que fazer com a sobrecarga?

Você faz uma lista de todos os avisos e avisos e segue as seguintes regras:

1. Nunca, em nenhuma circunstância, adicione um novo aviso à lista. Todo novo trecho de código, toda edição, toda alteração, todo patch, todo commit não deve introduzir novos avisos, ele só pode ser corrigido los.
2. Sempre que você tocar em um pedaço de código, corrija todos e quaisquer avisos nesse pedaço de código. (A regra do escoteiro: sempre deixe o acampamento em melhores condições do que você o encontrou.) Dessa forma, o código não importante pode ficar cheio de avisos, mas o código importante fica mais limpo com o tempo. "Parte do código" pode ser uma função, uma classe, um arquivo. Você também pode relaxar essa regra para corrigir pelo menos um aviso. O ponto é: conserte-os como você os encontra.

Nota: ambos requerem que você tenha algum tipo de banco de dados de log e mecanismo de filtragem de log em vigor. Observe também que "banco de dados de log" e "mecanismo de filtragem de log" podem ser apenas um arquivo de texto e grep.

Esta é a parte importante. Sem o banco de dados, você não saberá quando adicionar um novo aviso e, sem a filtragem, ainda terá o problema de sobrecarga.

Nota 2: isso não funciona apenas para avisos, mas também para verificadores de estilo, métricas de complexidade, cobertura de código, ferramentas de análise estática e assim por diante. Basicamente:

1. Não adicione novos problemas.
2. Corrija os problemas antigos enquanto os tropeça.

Isso permite que você priorize com facilidade: o código que é editado com frequência e, portanto, precisa ser fácil de ler e manter, ficará melhor com o tempo. Código que não é tocado frequentemente, não vai melhorar, mas tudo bem, porque ninguém precisa olhar para ele de qualquer maneira. E , pelo menos, não vai piorar.

Obviamente, nada impede você de alocar tempo especificamente para não fazer nada além de caçar e matar avisos. Frequentemente, isso não é economicamente viável, e é seu trabalho como engenheiro manter isso em mente. "Um engenheiro é aquele que pode construir com um dólar, o que qualquer tolo pode construir com dois."

Se avisos e avisos vierem do seu código, definitivamente o corrija. Pela minha experiência, em 95% pode ser benigno, mas os 5% destacam um problema real que pode levar a inúmeras horas gastas em perseguição.

Se eles vierem do código de terceiros que você deve usar por um motivo ou outro, geralmente não há muita escolha.

É uma questão diferente se a sua base de código herdada for realmente grande, você poderá tratar o código herdado como terceiros, mas exigir que o novo código seja livre de aviso.

Importa. Um aviso pode não interromper seus testes ou até aparecer na natureza por um tempo - mas pode ser um sintoma de um bug iminente. Atualmente, desenvolvo principalmente em C # / C ++ e tenho uma estratégia definida para se livrar e manter os avisos fora de nossa base de código. Felizmente, não é ciência do foguete =).

Se o idioma em que você trabalha tem a capacidade de tratar os avisos como erros e tem níveis de aviso variáveis, eu faria o seguinte:

1. Abaixe o nível de aviso apenas o suficiente para não receber nenhum aviso. Se você estiver no nível de aviso mais baixo e ainda receber avisos - tente corrigi-los. Se você não pode corrigi-los, está pronto por enquanto, mas espero que possa corrigi-los. Ótimo.
2. Como agora você não possui avisos (provavelmente em um nível de aviso baixo), gire a chave e trate todos os avisos como erros.
3. Tente aumentar o nível de aviso e corrija todos os novos avisos. Se não conseguir, diminua o nível de aviso, mas não desative os avisos como erros.

Acho que isso não só funciona como avisos do meu código - ele os mantém fora .