Principle: Naming is a design activity

Poor names (abbreviated, misleading, or overly generic) make code hard to understand and maintain.

Naming guidelines that improve code clarity:

Functions/methods: verb + noun, describe what they DO

# BAD
def process(data): ...      # Process how?
def handle(event): ...      # Handle how?
def do_stuff(items): ...    # What stuff?

# GOOD
def validate_email(email): ...
def calculate_shipping_cost(order): ...
def send_welcome_notification(user): ...

Booleans: is/has/can/should prefix

# BAD
active = True
error = False
permission = True

# GOOD
is_active = True
has_error = False
can_edit = True

Collections: plural nouns

# BAD
user_list = [...]   # Redundant 'list'
data = [...]        # Data of what?

# GOOD
users = [...]       # Clear it's a collection
pending_orders = [...]  # Specific

Avoid:

• Abbreviations: usr, btn, mgr (except universally known: id, url, http)
• Single letters (except loop counters i, j, k and lambdas)
• Meaningless prefixes: my_, the_, a_
• Type in name: user_list, name_string (Hungarian notation)
• Negated booleans: is_not_valid (use is_valid and negate)

Test: If you removed all comments, could someone understand the code from names alone?

You read code 10x more than you write it. Good names are documentation that never goes stale.

Writing readable, maintainable code in any language