Prefer explicit over concise

Choose explicit and unambiguous names over concise but unclear ones. When a method, type, or variable has a specific behavior or purpose, the name should clearly communicate that, even if it results in longer names.

For example:

• Use AsyncFdTryNewError instead of a generic error name to clearly indicate its purpose
• Choose AbortOnDropHandle over shorter alternatives to communicate the type’s behavior
• Prefer sender_strong_count() over strong_count() when the context requires clarity about which entity’s count is being returned
• Use notify_one_last_in() rather than notify_one_lifo() to make the behavior more obvious
• Name a method copy_bidirectional_with_sizes() instead of copy_bidirectional_with_size() when it takes multiple size parameters
• Choose clone_inner() over clone() to avoid confusion with the standard Clone trait implementation

While conciseness has value, clarity and explicitness should take precedence when there’s potential for ambiguity or confusion. This principle applies to all identifiers including variables, methods, functions, types, and modules.