A variable name is more than a unique label: it should help readers understand the value, purpose, or operation it represents. Names such as cool and uncool may seem amusing at first, but their meaning becomes difficult to recover as code grows. Meaningful names reduce that maintenance burden while remaining short enough to read and type comfortably. section 2.1 section 2.1.1
From shorthand to intent
Short names can hide the intent of an algorithm: t, i, j, r, and it reveal little about a two-dimensional table. Replacing them with table, row_index, row, column_index, and item makes the same iteration easier to understand without changing its behavior. section 2.1.1
table = [[12, 11, 4], [3, 22, 105], [0, 47, 31]]
for row_index, row in enumerate(table):
for column_index, item in enumerate(row):
process_item(row_index, column_index, item)
Compare the terse loop with its clearer version to see how names communicate structure and purpose. section 2.1.1
Apply the same judgment across ordinary application code and public interfaces:
- Prefer words that expose use: total, total_parttime_employees, first_name, and last_name communicate more than t, fname, or mname. section 2.1.1
- Balance meaning with brevity; names are worth choosing carefully because dependencies make them costly to change later. section 2.1.1
- Use meaningful snake_case names for functions, avoid unexplained abbreviations and domain-specific acronyms, and let docstrings add detail when needed. section 3.2.1
- Treat naming as part of maintainability alongside readable code, consistent style, comments, and flexible functions. section 1.3.2
