¿Es una mala práctica nombrar una variable no utilizada con un solo guión bajo?

A menudo, cuando la sintaxis del lenguaje requiere que nombre una variable que nunca se usa, la nombraré _.

En mi opinión, esto reduce el desorden y me permite centrarme en las variables significativas del código. Me parece discreto, por lo que produce un efecto "fuera de la vista, fuera de la mente".

Un ejemplo común de dónde hago esto es nombrar subconsultas en SQL.

SELECT *
FROM
(
    SELECT *
    FROM TableA
    JOIN TableB
        ON TableA.ColumnB = TableB.ColumnB
    WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC

Otro ejemplo es una variable de bucle que no se usa.

array = [[] for _ in range(n)] # Defines a list of n empty lists in Python

Utilizo esta técnica con moderación, solo cuando siento que un nombre descriptivo no agrega nada al código y, en cierto sentido, lo quita al agregar más nombres para recordar. De alguna manera, lo veo como similar a la varpalabra clave en C #, que también uso con moderación.

Mis compañeros de trabajo no están de acuerdo. Dicen que incluso tener un solo nombre de carácter (alfabético) es mejor que _.

¿Me equivoco? ¿Es una mala práctica hacer esto?

Todos los nombres deben ser significativos. Si _fuera un estándar bien conocido en su empresa o en la comunidad en general, entonces sería significativo como un "nombre que no importa". Si no es así, diría que es una mala práctica. Use un nombre descriptivo para lo que se refiere, especialmente porque el nombre podría ser importante en el futuro.

Yo diría que es una práctica aceptable. Este es un caso raro en el que consideraría que la mayoría está equivocada y necesita actualizar sus conocimientos sobre ideas de programación recientes. En muchos idiomas, particularmente los lenguajes funcionales basados ​​en ML como Haskell y OCaml, es extremadamente común usarlo _como una variable "no utilizada". Incluso Lua, que no ofrece soporte de lenguaje explícito para ello, fomenta el uso de _un marcador de posición por convención.

Varios idiomas (Haskell, Lua y DI piensan fuera de mi mente) también ofrecen una convención en la que las variables que comienzan con un guión bajo no generan advertencias del compilador sobre la "variable local no utilizada" que hace que _el nombre de la variable no utilizada sea más corto. Podrías usar algo como, _unusedpero estoy de acuerdo contigo en que solo hace desorden.

En Python _es definitivamente aceptable. Sin embargo, puede entrar en conflicto con gettextalias _().

Otras convenciones comunes son dummy, unused; solo o como prefijo.

Algunas herramientas de análisis de código conocen estas convenciones y no emitirán advertencias de variables no utilizadas:

• PyLint para _odummy
• PyDev para cualquier variable que comience por _, unusedodummy

Depende del ecosistema en el que va a vivir este código. Si _es un estándar aceptado para indicar "variable ficticia" / "salida no utilizada", entonces, por supuesto, quédese con él. Si no es así, averigüe qué es y úselo.

Algunos lenguajes de programación (por ejemplo, Haskell) incluso tienen este identificador 'especial' integrado en su sintaxis para los fines que usted menciona.

Cuidado, _ ya tiene un significado intrínseco en algunos idiomas

En Python:

9.6. Variables privadas y referencias locales de clase

ingrese la descripción del enlace aquí Las variables de instancia "privadas" a las que no se puede acceder, excepto desde el interior de un objeto, no existen en Python. Sin embargo, hay una convención seguida por la mayoría del código de Python: un nombre con un guión bajo (por ejemplo, _spam) debe tratarse como una parte no pública de la API (ya sea una función, un método o un miembro de datos) . Debe considerarse un detalle de implementación y estar sujeto a cambios sin previo aviso.

También hay otra mención en la PEP 8 (Guía de estilo para el código Python):

Descriptivo: Estilos de nombres

_single_leading_underscore: indicador débil de "uso interno". Por ejemplo, desde M import * no importa objetos cuyo nombre comience con un guión bajo.

Cía#:

Generalmente se usa para marcar variables privadas que tienen propiedades públicas / internas. Pero la práctica generalmente se desprecia en estos días .

En JavaScript:

Hay una biblioteca llamada underscore.js que usa el guión bajo como prefijo para las extensiones prototipo no estándar.

Ejemplo:

var object = { some:'stuff' };
var newObject = _.clone(object);

Lo que me lleva a mi punto. Lo que está mal con las convenciones de variables de marcador de posición clásico.

var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders

¿Por qué usar una convención personalizada que algunos pueden malinterpretar cuando ya hay muchas convenciones comunes disponibles?

Yo uso "ficticio" para ese tipo de cosas. O "basura", si solo estoy probando algo :) Nombre sus variables para describir cuáles son. Si son variables ficticias, no utilizadas, asígneles un nombre como tal.

Me parece una mala práctica porque

• no deberías tener una variable invisible en tu código. Si cree que debería, probablemente se debata la razón.

• el lenguaje Go usa esta palabra clave para indicar que ninguna variable es el destino de uno de los múltiples retornos de una función. Si su idioma no tiene múltiples retornos, no es necesario. Su convención de nomenclatura le hará daño el día que usará un idioma usando _ como notación de idioma estándar.

(No sé Python: ¿es realmente necesaria esta construcción?)

Puede ser sintácticamente válido y puede estar bien como parte de un estándar.

Dicho esto, es algo que le pediría a alguien que cambie en una revisión de código. Tampoco lo pondría en un estándar de codificación, y trataría de eliminarlo de uno existente. Es simplemente más difícil de leer, y no es muy significativo.

Creo que está mal porque:

1) Es más difícil de ver ya que no hay muchos píxeles.

2) Si hay más de uno _, ¿cómo sabes cuál? ¿O que un nuevo desarrollador ha "seguido las reglas" y ha mantenido su uso extremadamente local en su alcance?

3) Es una práctica que no es útil. Usar nombres de variables de una sola letra es muy antiguo (es decir, ¡mi educación original!) Los veré ... y luego veré comentarios agregados para decir lo que hace el código y esa es una mala práctica en el mundo de hoy. Utilizo nombres largos de variables tanto como sea posible para que todos, independientemente del nivel de programación o la familiaridad con el código, puedan "leerlo" casi como el inglés. Usar nombres de 1 letra es una práctica extremadamente común con código antiguo y con programadores más antiguos (nuevamente, me incluye a mí), pero eso no lo hace correcto.

Para evitar colisiones en el espacio de nombres y permitir la depuración, en caso de que el nombre de la variable sea su única pista, podría ser mejor llamarlo "join_ab_unused".

Inspirado por Birfl.

Sí, es una mala práctica por dos razones:

1. Prefijar una variable no utilizada con un guión bajo no es un estándar ampliamente aceptado. Es probable que se ignore a los "no iniciados".
2. He visto algunas personas prefijar variables de miembros privados con un guión bajo, y su estándar confundiría en gran medida a esas personas.

Lo que intenta hacer es codificar en una versión más bonita de SQL que no tenga el problema de obligarlo a inventar un nombre para algo inútil.

El guión bajo es casi invisible, por lo que parece que estás en ese idioma. Si solo se pudiera utilizar un espacio en blanco como identificador, sería perfecto, ¿verdad?

Pero no estás en un idioma diferente, y lo que estás haciendo no es una manera limpia de hacer una extensión de idioma.

Depende del idioma. En Java , sí, esto es malo y puede ser una tendencia peligrosa para agregar a su código, en gran parte porque las herramientas que usan la reflexión no manejan los guiones bajos muy bien, ya que están fuera de las convenciones de nombres variables de Java. En python , esto también es malo pero no tan malo. En clojure , está 100% bien, y de hecho, es idiomático usar _'s como marcadores de posición en una declaración let.

Recuerde que cada idioma tiene su propia sintaxis completa y un conjunto de expresiones idiomáticas, por lo que debe evaluar lo bueno / lo malo en términos de estas expresiones idiomáticas, en lugar de en términos absolutos.

Esto sería malo en perl, que usa $ _ (y a veces _) como una variable especial.

En general, me mantendría alejado de él solo porque el _ parece ser una variable específica del lenguaje. Si vi su código, estaría en la documentación buscando lo que era _, hasta que me di cuenta de que era solo un muñeco. No hay nada malo con DUMMY, $ DUMMY, lo que sea.

Evitaría los guiones bajos al comienzo de los vars a menos que esté seguro de que no tienden a indicar algo más en un idioma o marco dado en uso intensivo. Por ejemplo, en Python, un doble subrayado tiende a indicar una var. En JQuery y otras bibliotecas JS, un solo guión bajo tiende a indicar una var de reserva para sobrescribir espacios de nombres. También es una convención de nomenclatura popular para incluir archivos que a su vez tienden a transferirse al código que maneja las inclusiones en forma var.