Python长变量名命名规范咨询：缩写还是保留原名？

Great question—this is something a lot of Python developers grapple with, especially when balancing PEP8’s readability goals with the brevity we see in the standard library. Let’s break this down with practical, context-driven advice:

Core Principle: Readability First #

PEP8 doesn’t explicitly address long variable names, but its golden rule is "Readability counts." Before reaching for abbreviations, ask yourself: Will someone reading this code (including future you) immediately understand what the variable means?

• Avoid arbitrary abbreviations like vry_lng_var_nm—these force readers to decode your personal shorthand, which slows down comprehension and introduces ambiguity.
• A descriptive full name like very_long_variable_name (or better, a more specific name like customer_annual_subscription_revenue) is always preferable if it makes the code self-documenting.

What About the Standard Library’s Short Names? #

You’re right that many standard library modules/functions use short names (sys, os, csv, len, idx), but these aren’t random:

• They’re universally recognized abbreviations in programming or the domain (e.g., csv = comma-separated values, sys = system).
• Many are historical artifacts from Python’s early days, where brevity was prioritized for typing speed (a less relevant concern now with modern IDEs).
• They’re often used for high-frequency operations where a short name reduces visual clutter without losing meaning.

So feel free to use these universal abbreviations, but don’t invent your own unless they’re widely understood in your team or field (e.g., cfg for config, usr for user in a user-management context).

When to Consider Abbreviating #

Abbreviations make sense only in specific scenarios:

• High-frequency usage: If a variable appears dozens of times in a tight loop or function (e.g., idx instead of index), a short, universal abbreviation can clean up the code without sacrificing clarity.
• Clear context: If the surrounding code makes the variable’s meaning obvious (e.g., in a function processing order data, ord_id instead of order_id is acceptable).
• Team conventions: If your team has agreed on standard abbreviations (documented in a style guide), follow those to maintain consistency.

When to Keep the Full Name #

Stick with the full name if:

• The variable is used infrequently (a long name won’t clutter the code, and clarity is more important).
• The abbreviation isn’t widely understood (e.g., tmrfs for total_monthly_revenue_from_subscriptions is a nightmare for anyone new to the codebase).
• The variable’s meaning is nuanced or non-obvious (e.g., pending_refund_request_count is clearer than pend_ref_req_cnt).

Comments vs. Descriptive Names #

While you can use comments to explain short names, descriptive variable names are always better. Comments can become outdated as code changes, but variable names stay in sync with the logic they represent. Only use comments to supplement names if the abbreviation is necessary but not self-evident.

内容的提问来源于stack exchange，提问作者Sargsyan Grigor