Where and How Is the _ (Underscore) Variable Specified

Where and how is the _ (underscore) variable specified?

There is some special handling in the source to suppress the "duplicate argument name" error. The error message only appears in shadowing_lvar_gen inside parse.y, the 1.9.3 version looks like this:

static ID
shadowing_lvar_gen(struct parser_params *parser, ID name)
{
    if (idUScore == name) return name;
    /* ... */

and idUScore is defined in id.c like this:

REGISTER_SYMID(idUScore, "_");

You'll see similar special handling in warn_unused_var:

static void
warn_unused_var(struct parser_params *parser, struct local_vars *local)
{
    /* ... */
    for (i = 0; i < cnt; ++i) {
        if (!v[i] || (u[i] & LVAR_USED)) continue;
        if (idUScore == v[i]) continue;
        rb_compile_warn(ruby_sourcefile, (int)u[i], "assigned but unused variable - %s", rb_id2name(v[i]));
    }
}

You'll notice that the warning is suppressed on the second line of the for loop.

The only special handling of _ that I could find in the 1.9.3 source is above: the duplicate name error is suppressed and the unused variable warning is suppressed. Other than those two things, _ is just a plain old variable like any other. I don't know of any documentation about the (minor) specialness of _.

In Ruby 2.0, the idUScore == v[i] test in warn_unused_var is replaced with a call to is_private_local_id:

if (is_private_local_id(v[i])) continue;
rb_warn4S(ruby_sourcefile, (int)u[i], "assigned but unused variable - %s", rb_id2name(v[i]));

and is_private_local_id suppresses warnings for variables that begin with _:

if (name == idUScore) return 1;
/* ... */
return RSTRING_PTR(s)[0] == '_';

rather than just _ itself. So 2.0 loosens things up a bit.

Why does underscore's _.isUndefined(variable) give an error that variable is not defined?

When you ask for targetNode, it looks for a local variable, then in subsequent parent scopes until it reaches the end of the chain. If it still hasn't found it, there's an error.

typeof is special in that it works similar to a try..catch around getting the variable, and returning "undefined" in the catch. Non-native code (such as isUndefined) can't do that since the variable must be resolved in order to pass it to the function.

However, if the symbol is defined, it can be validly passed. For example:

function test(param) {
    console.log(_.isUndefined(param));
}
test("argument");
test(); // undefined argument

Or another example:

function test() {
    console.log(_.isUndefined(foo)); // true, no error due to hoisting
    var foo = 3;
    console.log(_.isUndefined(foo)); // false, foo is defined now.
}

You can also specify an explicit source, such as window.targetNode. window is defined, so the script knows where to look, however the targetNode property may not be defined, in which case you get undefined.

What is the purpose of the single underscore _ variable in Python?

_ has 3 main conventional uses in Python:

To hold the result of the last executed expression in an interactive
interpreter session (see docs). This precedent was set by the standard CPython
interpreter, and other interpreters have followed suit
For translation lookup in i18n (see the
gettext
documentation for example), as in code like
```
raise forms.ValidationError(_("Please enter a correct username"))
```
As a general purpose "throwaway" variable name:
1. To indicate that part
  of a function result is being deliberately ignored (Conceptually, it is being discarded.), as in code like:
```
label, has_label, _ = text.partition(':')
```
2. As part of a function definition (using either def or lambda), where
  the signature is fixed (e.g. by a callback or parent class API), but
  this particular function implementation doesn't need all of the
  parameters, as in code like:
```
def callback(_):
    return True
```
  [For a long time this answer didn't list this use case, but it came up often enough, as noted here, to be worth listing explicitly.]
This use case can conflict with the translation lookup use case, so it is necessary to avoid using _ as a throwaway variable in any code block that also uses it for i18n translation (many folks prefer a double-underscore, __, as their throwaway variable for exactly this reason).
Linters often recognize this use case. For example year, month, day = date() will raise a lint warning if day is not used later in the code. The fix, if day is truly not needed, is to write year, month, _ = date(). Same with lambda functions, lambda arg: 1.0 creates a function requiring one argument but not using it, which will be caught by lint. The fix is to write lambda _: 1.0. An unused variable is often hiding a bug/typo (e.g. set day but use dya in the next line).
The pattern matching feature added in Python 3.10 elevated this usage from "convention" to "language syntax" where match statements are concerned: in match cases, _ is a wildcard pattern, and the runtime doesn't even bind a value to the symbol in that case.
For other use cases, remember that _ is still a valid variable name, and hence will still keep objects alive. In cases where this is undesirable (e.g. to release memory or external resources) an explicit del name call will both satisfy linters that the name is being used, and promptly clear the reference to the object.

Use underscore as variable in Parallel Assignment

In parallel assignment, we sometimes do two things :

ignore one element ( taking care of _)

You can reuse an underscore to represent any element you don’t care about:

a, _, b, _, c = [1, 2, 3, 4, 5]

a # => 1
b # => 3
c # => 5

ignore multiple elements ( taking care of * )

To ignore multiple elements, use a single asterisk — I’m going to call it a ‘naked splat’ for no better reason than that it sounds a bit amusing:

a, *, b = [1, 2, 3, 4, 5]

a # => 1
b # => 5

Read this blog post Destructuring assignment in Ruby to know more other related things.

Underscore as a JavaScript variable?

I've seen the underscore used to denote that the variable is a "don't care" variable. It means that it doesn't matter and isn't used at all.

In the case you pointed out, it was used to signify that his function had two arguments, but he only needed the second one.

What is the purpose of the underscore after variable name and comma?

In many programming languages _ is used to denote unused variables.

This is also applicable to Lua. It is pure style convention. You won't find anything about it in the Lua manual.

luackeck, the most common static code analyzer for Lua will give you warnings for having unused variables in your code. It will ignore variables named _ in that regard.

Wouldn't be name = name:gsub(....) or ..then path = path:gsub(...) the
same ?

In your examples this is actually not necessary.

The only reason to have _ in name, _ = name:gsub("{", "\\{") would be to give a hint that this function actually returns two values. Usually you would leave the _ away.

Whereas _, numReplaced = name:gsub("{", "\\{") would make sense if you're only interested in the second return value. You cannot get that without adding the first unused variable.

What are the rules about using an underscore in a C++ identifier?

The rules (which did not change in C++11):

Reserved in any scope, including for use as implementation macros:
- identifiers beginning with an underscore followed immediately by an uppercase letter
- identifiers containing adjacent underscores (or "double underscore")
Reserved in the global namespace:
- identifiers beginning with an underscore
Also, everything in the std namespace is reserved. (You are allowed to add template specializations, though.)

From the 2003 C++ Standard:

17.4.3.1.2 Global names [lib.global.names]

Certain sets of names and function signatures are always reserved to the implementation:

Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.¹⁶⁵

¹⁶⁵⁾ Such names are also reserved in namespace ::std (17.4.3.1).

Because C++ is based on the C standard (1.1/2, C++03) and C99 is a normative reference (1.2/1, C++03) these also apply, from the 1999 C Standard:

7.1.3 Reserved identifiers

Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces.

Each macro name in any of the following subclauses (including the future library
directions) is reserved for use as specified if any of its associated headers is included;
unless explicitly stated otherwise (see 7.1.4).

All identifiers with external linkage in any of the following subclauses (including the
future library directions) are always reserved for use as identifiers with external
linkage.¹⁵⁴

Each identifier with file scope listed in any of the following subclauses (including the
future library directions) is reserved for use as a macro name and as an identifier with
file scope in the same name space if any of its associated headers is included.

No other identifiers are reserved. If the program declares or defines an identifier in a
context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined.

If the program removes (with #undef) any macro definition of an identifier in the first
group listed above, the behavior is undefined.

¹⁵⁴⁾ The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp, and va_end.

Other restrictions might apply. For example, the POSIX standard reserves a lot of identifiers that are likely to show up in normal code:

Names beginning with a capital E followed a digit or uppercase letter:
- may be used for additional error code names.
Names that begin with either is or to followed by a lowercase letter
- may be used for additional character testing and conversion functions.
Names that begin with LC_ followed by an uppercase letter
- may be used for additional macros specifying locale attributes.
Names of all existing mathematics functions suffixed with f or l are reserved
- for corresponding functions that operate on float and long double arguments, respectively.
Names that begin with SIG followed by an uppercase letter are reserved
- for additional signal names.
Names that begin with SIG_ followed by an uppercase letter are reserved
- for additional signal actions.
Names beginning with str, mem, or wcs followed by a lowercase letter are reserved
- for additional string and array functions.
Names beginning with PRI or SCN followed by any lowercase letter or X are reserved
- for additional format specifier macros
Names that end with _t are reserved
- for additional type names.

While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of that standard.

Personally I just don't start identifiers with underscores. New addition to my rule: Don't use double underscores anywhere, which is easy as I rarely use underscore.

After doing research on this article I no longer end my identifiers with _t
as this is reserved by the POSIX standard.

The rule about any identifier ending with _t surprised me a lot. I think that is a POSIX standard (not sure yet) looking for clarification and official chapter and verse. This is from the GNU libtool manual, listing reserved names.

CesarB provided the following link to the POSIX 2004 reserved symbols and notes 'that many other reserved prefixes and suffixes ... can be found there'. The
POSIX 2008 reserved symbols are defined here. The restrictions are somewhat more nuanced than those above.

What does variable names beginning with _ mean?

There's no language-defined meaning - it's just a convention some people use to distinguish instance variables from local variables. Other variations include m_foo (and s_foo or g_foo or static variables) or mFoo; alternatively some people like to prefix the local variables (and parameters) instead of the instance variables.

Personally I don't use prefixes like this, but it's a style choice. So long as everyone working on the same project is consistent, it's usually not much of an issue. I've seen some horribly inconsistent code though...

Is there a standard in java for _ (underscore) in front of variable or class names?

It is a matter of personal taste.

Martin Fowler appears to like it. I don't care much for it - it breaks the reading pattern, and the information it conveys is already subtly told by color in your IDE.

I've experimented with using _ as the name of the variable holding the result to be returned by a method. It is very concise, but I've ended up thinking that the name result is better.

So, get your colleagues to agree on what you all like the most and then just do that.

Where and How Is the _ (Underscore) Variable Specified