Poor Logging Practice: Use of a System Output Stream

Si se utilizan Console.Out o Console.Error en lugar de una interfaz de registro dedicada, es difícil supervisar el comportamiento del programa.

Ejemplo 1: el primer programa .NET que un desarrollador aprende a escribir es el siguiente:

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

Mientras que la mayoría de los programadores continúan con el aprendizaje de matices y detalles de .NET, un número sorprendente se queda en esta primera lección y no deja de escribir mensajes a salida estándar utilizando Console.WriteLine().

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando ya ha pasado las primeras fases del desarrollo, el uso de Console.WriteLine podría indicar un descuido en el paso a un sistema de registro estructurado.

Si se utilizan os.Stdout o os.Stderr en lugar de una interfaz de registro dedicada, es difícil supervisar el comportamiento del programa.

Ejemplo 1: Generalmente, el primer programa Go que un desarrollador aprende a escribir es el siguiente:

...

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

Si bien muchos desarrolladores continúan aprendiendo los matices y las sutilezas de Go, algunos nunca dejan de escribir mensajes para salida estándar mediante fmt.Println().

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, identificador de registrador, marcas de tiempo y la capacidad de dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registradores de forma adecuada, el resultado normalmente es un registro en buen estado al que le falta información esencial.

El registro estructurado es ampliamente aceptado, pero muchos desarrolladores siguen usando los flujos de salida del sistema en su desarrollo "previo a la producción". Si el código que está revisando ha superado las fases iniciales de desarrollo, el registro en os.Stdout o os.Stderr puede indicar un descuido en el paso a un sistema estructurado de registro.

Si se utiliza process.stdout o process.stderr en lugar de una interfaz de registro dedicada, resulta más difícil supervisar el comportamiento del programa.

Ejemplo 1: Un programa simple que un desarrollador temprano de Node.js puede escribir para leer desde stdin y volver a escribirlo en stdout nuevamente puede tener el siguiente aspecto:

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

Aunque la mayoría de los programadores continúan aprendiendo los matices y las sutilezas de JavaScript y Node.js, muchos de ellos se quedan en esta primera lección y nunca dejan de escribir mensajes para salida estándar utilizando process.stdout.write().

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando está más allá de las fases iniciales de desarrollo, el uso de process.stdout o process.stderr podría indicar un descuido en el paso a un sistema estructurado de registro.

Si se utilizan print o println en lugar de una interfaz de registro dedicada, es difícil supervisar el comportamiento del programa.

Ejemplo 1: el primer programa Kotlin que un desarrollador aprende a escribir es el siguiente:

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

Aunque la mayoría de los programadores continúan aprendiendo los matices y las sutilezas de Kotlin, una cantidad sorprendente de ellos se quedan en esta primera lección y nunca dejan de escribir mensajes para salida estándar usando print o println.

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando está más allá de las fases iniciales de desarrollo, el uso de la secuencia de error o salida estándar podría indicar un descuido en el paso a un sistema estructurado de registro.

Si se utiliza salida estándar o error estándar, en lugar de una interfaz de registro dedicada, resulta más difícil supervisar el comportamiento del programa.

Ejemplo 1: El primer programa Python que un desarrollador aprende a escribir normalmente tiene el siguiente aspecto:

sys.stdout.write("hola, mundo")

Aunque muchos programadores continúan aprendiendo los matices y sutilezas de Python, una cantidad sorprendente de ellos se quedan en esta primera lección y nunca dejan de escribir mensajes para salida estándar.

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando está más allá de las fases iniciales de desarrollo, el uso de sys.stdout o sys.stderr podría indicar un descuido en el paso a un sistema estructurado de registro.

Si se utiliza Kernel.puts,Kernel.warn o Kernel.printf en lugar de una interfaz de registro dedicada, resulta más difícil supervisar el comportamiento del programa.

Ejemplo 1: el primer programa de Ruby que aprende a escribir un desarrollador a menudo incluye una función como:

...
puts "hello world"
...

Aunque muchos programadores continúan aprendiendo los matices y sutilezas de Ruby, una cantidad sorprendente de ellos se quedan en esta primera lección y nunca dejan de escribir mensajes para salida estándar usando Kernel.puts.

El problema es que escribir directamente a salida estándar o error estándar a menudo se utiliza como una forma no estructurada de registro. Las interfaces de registro estructuradas proporcionan características como niveles de registro, formateo uniforme, un identificador de registros, marcas de tiempo y, puede que de forma más crítica, la capacidad para dirigir mensajes de registro al sitio adecuado. Cuando el uso de los flujos de salida del sistema se confunde con el código que utiliza los registros de forma adecuada, a menudo el resultado es un registro en buen estado al que le falta información esencial.

Los desarrolladores aceptan ampliamente la necesidad de los registros estructurados, aunque muchos siguen utilizando los flujos de salida del sistema en el desarrollo de "pre-producción". Si el código que está revisando está más allá de las fases iniciales de desarrollo, el uso de Kernel.puts,Kernel.warn o Kernel.printf podría indicar un descuido en el paso a un sistema estructurado de registro.
Si hay una directiva de la empresa que no permite el uso de estas API, esto aún se podría solucionar mediante el uso de un sistema de registro para, a continuación, imprimir la información en un flujo de salida del sistema.

Ejemplo 2: El siguiente código utiliza la clase Logger, pero registra información en un flujo de salida del sistema:

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