Is it bad practice to name an unused variable with a single underscore?

Question

Often when the syntax of the language requires me to name a variable that is never used, I'll name it _.

In my mind, this reduces clutter and lets me focus on the meaningful variables in the code. I find it to be unobtrusive so that it produces an "out of sight, out of mind" effect.

A common example of where I do this is naming subqueries in 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

Another example is a loop variable that isn't used.

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

I use this technique very sparingly, only when I feel that a descriptive name adds nothing to the code, and in some sense takes away from it by adding more names to remember. In some ways I view it as similar to the var keyword in C#, which I also use sparingly.

My coworkers disagree. They say that even having a single (alphabetic) character name is better than _.

Am I wrong? Is it bad practice to do this?

Answer 1

All names should be meaningful. If _ was a well known standard at your company or in the wider community, then it would be meaningful as a "name that does not matter". If it's not, I would say it's bad practice. Use a descriptive name for what you refer to, especially since the name might matter in the future.

Answer 2

I would say that it's an acceptable practice. This is a rare instance where I would consider the majority to be wrong and in need of updating their knowledge of recent programming ideas. In many languages, particularly ML-based functional languages like Haskell and OCaml, it is extremely common to use _ as an "unused" variable. Even Lua, which doesn't offer explicit language support for it, encourages the use of _ as a placeholder by convention.

Several languages (Haskell, Lua, and D I think off the top of my head) also offer a convention where variables that lead off with an underscore don't generate compiler warnings about "unused local variable" which makes _ the shortest unused variable name. You could use something like _unused but I agree with you that it just makes clutter.

Answer 3

In Python _ is definitively acceptable. It can however conflict with gettext alias _().

Other common conventions are dummy, unused; alone or as prefix.

Some code analysis tools are aware of these conventions and will not issue unused variable warnings:

• PyLint for _ or dummy
• PyDev for any variable starting with _, unused or dummy

Answer 4

It depends on the ecosystem that this code is going to live in. If _ is an accepted standard to indicate "dummy variable" / "unused output", then by all means, stick with it. If it's not, find out what is and use that.

Some programming languages (e.g. Haskell) even have this 'special' identifier built into their syntax for exactly the purposes you mention.

Answer 5

Careful, _ already has an intrinsic meaning in some languages

In Python:

9.6. Private Variables and Class-local References

enter link description here“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

There's also another mention in the PEP 8 (Style Guide for Python Code):

Descriptive: Naming Styles

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

In C#:

It's generally used to mark private variables that have public/internal properties. But the practice is generally looked down on these days.

In JavaScript:

There is a library called underscore.js that uses the underscore as a prefix for non-standard prototype extensions.

Example:

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

---

Which leads me to my point. What's wrong with the classic placeholder variable conventions.

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

Why use a custom convention that some may misinterpret when there are plenty of common conventions available already?

Answer 6

I use "dummy" for that sort of thing. Or "crap", if I'm just testing something out :) Name your variables to describe what they are. If they're dummy, unused variables, name them as such.

Answer 7

It depends on the language. In java, yes this is bad and can be a dangerous trend to add to your code, largely because tools that use reflection don't handle underscores very well, since they are outside of java variable naming conventions. In python, this is also bad but not as bad. In clojure , its 100% okay, and in fact, its idiomatic to use _'s as place holders in a let statement.

Remember that each language has its own entire syntax and set of idioms, so you have to evaluate good/bad in terms of these idioms, rather than in absolute terms.

Answer 8

I find it to be bad practice because

• you should not have invisible variable in your code. If you feel you should the reason could probably be discussed.

• the Go language uses this keyword to indicate that no variable is the destination of one of the multiple returns of a function. If your language hasn't multiple returns it's not needed. Your naming convention will hurt you the day you'll use a language using _ as a standard language notation.

(I don't know Python : is this construct really needed ?)

Answer 9

It may be syntactically valid, and it might be OK as part of a standard.

With that said, it is something I would ask someone to change in a code review. I would also never put it into a coding standard, and would try to remove it from an existing one. It's just more difficult to read, and not super meaningful.

Answer 10

To avoid namespace collisions, and allow for debugging, in case that variable name is your only clue, it might be better to call it "joined_ab_unused".

Inspired by Birfl.

Answer 11

What you're trying to do is to code in a nicer version of SQL which doesn't have the issue of forcing you to invent a name for something useless.

The underscore is almost invisible, so it looks like you are in that language. If only whitespace could be used as an identifier, it would be perfect, right?

But you are not in a different language, and what you're doing is not a clean way to make a language extension.

Answer 12

This would be bad in perl, which uses $_ (and sometimes _) as a special variable.

In general, I'd stay away from it just because the _ seems to be a language specifmetavariable. If I saw your code, I'd be in documentation looking for what _ was, until I realized it was just a dummy. Nothing wrong with DUMMY, $DUMMY, whatever.

Answer 13

I would avoid underscores at the beginning of vars unless you were certain they didn't tend to indicate something else in a given language or framework in heavy use. For instance, in Python, a double underscore tends to indicate a magic var. In JQuery and other JS libraries a single underscore tends to indicate a fallback var for namespace overwrites. It's also a popular naming convention for include files which in turn tend to carry over to code that handles includes in var form.

Answer 14

These things are language dependent. And what is appropriate for developers using one language is inappropriate for another.

In Swift, there are situations where you should use a plain underscore. There are even situations where the compiler tells you to use an underscore instead of a variable name. Assigning a function result to underscore is about the same as casting a function result to void in C or C++.

Answer 15

Yes, it's a bad practice for two reasons:

1. Prefixing a unused variable with an underscore isn't a widely accepted standard.* It will likely be ignored the "uninitiated".
2. I've seen some people prefix private member variables with an underscore, and your standard would greatly confuse such people.

---

• 2023 Update: C# is now promoting the discard placeholder variable: _.

Answer 16

I think it's wrong because:

1) It's harder to see as there's not many pixels.

2) If there's more than one _, how do you know which one? - or that a new developer has 'followed the rules' and kept their use extremely local in scope?

3) It's an practice that is not helpful. Using single letter variable names is so old school (i.e. my original education!). I'll see them... and then see comments added to say what the code does and that's a bad practice in today's world. I use long variables names as much as possible so everyone, regardless of programming level or familiarity with the code can just "read it" almost like english. Using 1 letter names is an extremely common practice with older code and with older programmers (again, includes me) but that does not make it ok.