Poor Logging Practice: Use of a System Output Stream

O uso de Console.Out ou Console.Error no lugar de um recurso dedicado de registro em log dificulta o monitoramento do comportamento do programa.

Exemplo 1: O primeiro programa .NET que um programador aprende a escrever geralmente é o seguinte:

public class MyClass {
  ...
    Console.WriteLine("hello world");
  ...
}

Embora a maioria dos programadores siga em frente e aprenda muitas nuances e sutilezas sobre o .NET, um número surpreendente permanece nessa primeira lição e nunca desiste de escrever mensagens para a saída padrão utilizando Console.WriteLine().

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando já tiver passado das fases iniciais de desenvolvimento, o uso de Console.WriteLine pode indicar um descuido na mudança para um sistema de registro em log estruturado.

O uso de os.Stdout ou os.Stderr no lugar de um recurso dedicado de registro em log dificulta o monitoramento do comportamento do programa.

Exemplo 1: Normalmente, O primeiro programa Go que um desenvolvedor aprende a escrever é o seguinte:

...

func foo(){
    fmt.Println("Hello World")
}

Embora a maioria dos desenvolvedores siga em frente e aprenda muitas nuances e sutilezas sobre o Go, alguns nunca desistem de escrever mensagens para a saída padrão utilizando fmt.Println().

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora e a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido, mas ao qual faltam informações críticas.

O registro em log estruturado é amplamente aceito, mas muitos desenvolvedores continuam a usar fluxos de saída do sistema em seu desenvolvimento de “pré-produção”. Se o código que você está analisando já passou das fases iniciais de desenvolvimento, o registro em log no os.Stdout ou os.Stderr pode indicar um descuido na mudança para um sistema de registro em log estruturado.

O uso de process.stdout ou process.stderr no lugar de um recurso dedicado de registro em log dificulta o monitoramento do comportamento do programa.

Exemplo 1: Um programa simples que um desenvolvedor de Node.js inicial pode escrever para ler de stdin e gravá-lo novamente em stdout pode ter a seguinte aparência:

process.stdin.on('readable', function(){
    var s = process.stdin.read();
    if (s != null){
      process.stdout.write(s);
    }
});

Embora a maioria dos programadores siga em frente e aprenda muitas nuances e sutilezas sobre o JavaScript e o Node.js em especial, muitos permanecem nessa primeira lição e nunca desiste de escrever mensagens para a saída padrão utilizando process.stdout.write().

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando já passou das fases iniciais de desenvolvimento, o uso de process.stdout ou process.stderr pode indicar um descuido na mudança para um sistema de registro em log estruturado.

O uso de print ou println no lugar de um recurso dedicado de registro em log dificulta o monitoramento do comportamento do programa.

Exemplo 1: O primeiro programa Kotlin que um programador aprende a escrever geralmente é o seguinte:

class MyClass {
    ...
            println("hello world")
    ...
    }
}

Enquanto a maioria dos programadores vai em frente e aprende muitas nuances e sutilezas sobre o Kotlin, um número surpreendente permanece nessa primeira lição e nunca desiste de escrever mensagens para a saída padrão utilizando print ou println.

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando passou das fases iniciais de desenvolvimento, o uso da saída padrão ou do fluxo de erros pode indicar um descuido na mudança para um sistema de registro em log estruturado.

Usar a saída padrão ou erro padrão em vez de um recurso de registro dedicado torna difícil monitorar o comportamento do programa.

Exemplo 1: O primeiro programa em Python que um desenvolvedor aprende a escrever costuma ser o seguinte:

sys.stdout.write("hello world")

Embora a maioria dos programadores aprenda posteriormente muitas das nuances e sutilezas do Python, um número surpreendente deles permanece nessa primeira lição e continua a escrever mensagens na saída padrão.

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando já passou das fases iniciais de desenvolvimento, o uso de sys.stdout ou sys.stderr pode indicar um descuido na mudança para um sistema de registro em log estruturado.

Usar Kernel.puts, Kernel.warn ou Kernel.printf em vez de um recurso de registro em log dedicado torna difícil monitorar o comportamento do programa.

Exemplo 1: O primeiro programa Ruby que um desenvolvedor aprende a escrever, muitas vezes, inclui funcionalidades como:

...
puts "hello world"
...

Embora a maioria dos programadores siga em frente e aprenda muitas nuances e sutilezas sobre o Ruby, um número surpreendente permanece nessa primeira lição e nunca desiste de escrever mensagens para a saída padrão utilizando Kernel.puts.

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando já tiver passado das fases iniciais de desenvolvimento, o uso de Kernel.puts,Kernel.warn or Kernel.printf pode indicar um descuido na alteração para um sistema de registro em log estruturado.
Se houver uma política da empresa de não usar essas APIs, isso ainda poderia ser contornado por meio da utilização de um sistema de registro em log para imprimir as informações em um fluxo de saída do sistema.

Exemplo 2: Este código usa a classe Logger, mas registra informações em um fluxo de saída do sistema:

require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...