Why Programmers Use Underscores in Variable Names

1. Single underscore prefix (`_variable`) — Conventionally indicates 'protected' or 'internal use only' variables. In Python, names starting with `_` aren't imported by `from module import *`. It's a soft warning to other developers: "This is for internal implementation, don't touch it directly."

2. Double underscore prefix (`__private`) — Triggers Python's name mangling. The variable is renamed to `_ClassName__private` to prevent accidental overriding in subclasses. Not true privacy (can still be accessed with the mangled name), but prevents naming collisions in inheritance hierarchies.

3. Double underscore surround (`__init__`) — 'Dunder' (double underscore) methods in Python. These are special methods that Python calls automatically in specific contexts. `__init__` initializes objects, `__str__` provides string representation, `__len__` enables `len()` support, etc.

4. Trailing underscore (`class_`, `type_`) — Used to avoid naming conflicts with Python keywords or built-in functions. When you need a variable named 'class' (a keyword), use `class_` instead. Also used for avoiding shadowing: `list_` instead of `list` (which would shadow the built-in `list`).

5. Snake_case (`user_profile_picture`) — The standard naming convention in Python for variables, functions, and methods. Uses underscores between words for readability. Much clearer than camelCase for longer, descriptive names common in Python codebases.

Python class with all underscore types:

class UserAccount:
    def __init__(self, username, class_):  # trailing underscore avoids 'class' keyword
        self.username = username
        self._protected_data = {}          # single underscore: internal use
        self.__private_key = hash(username) # double underscore: name mangling
        self.class_type = class_           # trailing underscore in variable name
    
    def __str__(self):                     # dunder method
        return f"User: {self.username}"
    
    def get_public_info(self):             # snake_case method name
        return {"username": self.username}

JavaScript with modern and legacy conventions:

// Modern JavaScript (ES2022+)
class UserAccount {
    #privateBalance = 0;          // True private field
    _legacyPrivate = 0;           // Convention-only private
    PUBLIC_CONSTANT = "USER";     // Constant in UPPER_SNAKE_CASE
    
    constructor(username) {
        this.username = username; // Public property (camelCase)
    }
    
    // Public method (camelCase)
    getPublicInfo() {
        return {
            username: this.username,
            constant: this.PUBLIC_CONSTANT
        };
    }
}

Follow the language's dominant convention.Python uses snake_case and `_private`. JavaScript uses camelCase and `#private`. Ruby uses snake_case and `@instance_variable`. Don't mix conventions within a project.

Use underscores for clarity, not obfuscation.The goal is to communicate intent to other developers. `_internal_data` says "this is for internal use." `__mangled_name` says "don't override this in subclasses."

Be consistent within your codebase.If you start using `_prefix` for internal methods, use it everywhere. If you use `CONSTANTS` for configuration values, don't mix with `regularVariables`.

Understand the actual behavior.Python's `__private` causes name mangling. JavaScript's `#private` is truly private. C's `_variable` is reserved. Know what the underscores actually do in your language.

When in doubt, look at popular projects.Check how major open-source projects in your language use underscores. Django (Python), React (JavaScript), Rails (Ruby) — these establish community conventions.