Self-documenting identifier names

Use clear, self-documenting names for variables, methods, and classes that express intent without exposing unnecessary implementation details.

For methods and variables:

• Avoid abbreviations unless universally understood (use connection instead of conn, source_location instead of line)
• Follow natural language patterns with adjectives before nouns (use allowed_redirect_hosts instead of redirect_hosts_allowed)
• Remove implementation details from public API names (use compute_checksum instead of compute_checksum_in_chunks)

For error classes:

• Follow the “what? kind?” pattern (e.g., ChecksumUnsupportedError instead of UnsupportedChecksumError)
• Make names descriptive enough to understand the problem (use MissingRequiredOrderError instead of OrderError)
• Match existing conventions (like AssociationNotFoundError for consistency with HasManyThroughAssociationNotFoundError)

For method signatures:

• Choose concise yet descriptive names for parameters and methods
• Avoid overly verbose names like supports_disabling_use_of_index_for_queries? when supports_disabling_indexes? would suffice

Remember that code is read far more often than it’s written. Thoughtful naming reduces cognitive load for future readers.