Choose names that clearly convey their purpose and avoid ambiguous identifiers that can be misinterpreted. This applies to methods, variables, parameters, and types.
Choose names that clearly convey their purpose and avoid ambiguous identifiers that can be misinterpreted. This applies to methods, variables, parameters, and types.
Key principles:
Examples:
Instead of confusing boolean parameters:
// Bad - unclear what true/false means
fn parse_inner(s: &str, allow_subdomain_wildcard: bool)
// Good - descriptive enum makes intent clear
enum SubdomainWildcardSupport {
Enabled,
#[default]
Disabled
}
fn parse_inner(s: &str, wildcard_support: SubdomainWildcardSupport)
Instead of ambiguous method names:
// Bad - unclear what this cancels
fn op_read_cancel()
// Good - clearly describes the operation
fn op_read_with_cancel_handle()
// Bad - too generic when context matters
fn get_usage()
// Good - specific to the type of usage
fn get_cpu_usage()
Instead of unclear type names:
// Bad - not descriptive enough
struct Unconfigured
// Good - clearly describes the state
struct UnconfiguredRuntime
This practice is especially important in permission-related code and public APIs where clarity prevents misuse and security issues.
Enter the URL of a public GitHub repository