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

Todos los nombres deben ser significativos. Si _ era un estándar bien conocido en su empresa o en la comunidad en general, sería significativo como un "nombre que no importa". Si no lo es, diría que es una mala práctica. Use un nombre descriptivo para lo que hace referencia, especialmente porque el nombre puede 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 que necesita actualizar su conocimiento de ideas de programación recientes. En muchos idiomas, particularmente en los lenguajes funcionales basados en ML como Haskell y OCaml, es extremadamente común usar _ como una variable "no utilizada". Incluso Lua, que no ofrece soporte de lenguaje explícito para él, fomenta el uso de _ como marcador de posición por convención.

Varios idiomas (Haskell, Lua y DI se me salen de la cabeza) también ofrecen una convención en la que las variables que comienzan con un guión bajo no generan advertencias del compilador sobre "variable local no utilizada" que hace que _ el nombre de la variable no utilizada más corto. Podría usar algo como _unused , pero estoy de acuerdo con usted en que solo hace desorden.

En Python _ es definitivamente aceptable. Sin embargo, puede entrar en conflicto con gettext alias _() .

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 _ o dummy
• PyDev para cualquier variable que comience con _ , unused o dummy

Depende del ecosistema en el que vaya a vivir este código. Si _ es un estándar aceptado para indicar "variable ficticia" / "salida no utilizada", entonces, cúmplalo. Si no lo es, averigüe qué es y use eso.

Algunos lenguajes de programación (por ejemplo, Haskell) incluso tienen este identificador "especial" incorporado en su sintaxis para los propósitos que mencionas.

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

En Python:

  

9.6. Variables privadas y referencias de clase local

     

ingrese la descripción del enlace aquí variables de instancia "privadas" a las que no se puede acceder, excepto desde dentro de un El objeto no existe 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 (p. Ej. _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 está sujeto a cambios sin previo aviso.

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

  

Descriptivo: Nombrando estilos

     

_single_leading_underscore: indicador débil de "uso interno". P.ej. from M import * no importa objetos cuyo nombre comience por un guión bajo.

En C #:

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

En JavaScript:

Hay una biblioteca llamada underscore.js que usa el carácter de subrayado como prefijo para las extensiones de prototipo no estándar.

Ejemplo:

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

Lo que me lleva a mi punto. ¿Qué hay de malo con las convenciones de variables de marcadores de posición clásicas?

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?

Uso "dummy" para ese tipo de cosas. O "mierda", si solo estoy probando algo :) Nombra tus variables para describir lo que son. Si son variables ficticias, no utilizadas, nómbrelas como tales.

Me parece que es una mala práctica porque

• no debes tener una variable invisible en tu código. Si crees que deberías, la razón podría ser discutida.

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

(No sé Python: ¿se necesita realmente 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. También nunca lo pondría en un estándar de codificación, y trataría de eliminarlo de uno existente. Es más difícil de leer, y no 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 un _ , ¿cómo sabes cuál? ¿O que un nuevo desarrollador ha "seguido las reglas" y ha mantenido su uso con un alcance extremadamente local?

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 qué hace el código y eso es una mala práctica en el mundo de hoy. Uso los 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 una letra es una práctica muy común con códigos más antiguos y con programadores más antiguos (de nuevo, me incluye) 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 "joined_ab_unused".

Inspirado por Birfl.

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

1. El prefijo de una variable no utilizada con un guión bajo no es un estándar ampliamente aceptado. Probablemente se ignorará a los "no iniciados".
2. He visto el prefijo de algunas personas variables de miembros privados con un guión bajo, y su estándar en gran medida confundirá a tales personas.

Lo que estás tratando de hacer es codificar una versión mejor de SQL que no tenga el problema de obligarte a inventar un nombre para algo inútil.

El subrayado es casi invisible, por lo que parece que estás en ese idioma. Si solo se pudiera usar el espacio en blanco como identificador, sería perfecto, ¿no?

Pero no estás en un idioma diferente, y lo que estás haciendo no es una forma clara de crear 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 denominación de variables de java. En python , esto también es malo pero no tan malo. En clojure , su 100% está bien, y de hecho, es idiomático usar _'s como marcadores de posición en una declaración de dejar.

Recuerde que cada idioma tiene su propia sintaxis y conjunto de modismos, por lo que debe evaluar bueno / malo en términos de estos idiomas, en lugar de en términos absolutos.

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

En general, me mantendría alejado de él solo porque _ parece ser un lenguaje específico. Si viera tu código, estaría en la documentación buscando lo que era _, hasta que me di cuenta de que era solo un maniquí. No hay nada malo con DUMMY, $ DUMMY, lo que sea.

Evitaría los guiones bajos al comienzo de las variables a menos que estuviera seguro de que no tienden a indicar otra cosa en un lenguaje o marco dado en uso intensivo. Por ejemplo, en Python, un subrayado doble tiende a indicar una var mágica. En JQuery y otras bibliotecas de JS, un solo guión bajo tiende a indicar una var de reserva para sobrescrituras de espacio de nombres. También es una convención de nomenclatura popular para los archivos de inclusión que, a su vez, tienden a transferirse al código que maneja las entradas de forma variable.