Awesome Reviewers

Adopt naming conventions that are (1) case-consistent by identifier kind and (2) semantically self-documenting (what it represents/includes/excludes, and what the function returns).

Rules

1. Identifier case consistency
   • Use camelCase for functions and global/server variables.
   • Use snake_case for local variables.
   • Do not mix styles in the same function/scope.
2. Names must encode meaning
   • For metrics/fields/helpers, include/exclude behavior must be evident from the name (or be explicitly documented next to the declaration).
   • Prefer names like *Shared* / *Unshared* when inclusion varies.
3. Function names must match behavior
   • If a function returns a boolean/status (e.g., 0/1), the return meaning must be reflected in the name (e.g., should..., try..., is...) or the code should clearly define it in the comment immediately above the function.
   • Align with existing naming patterns (e.g., clientsCronRunClient-style).
4. Avoid ambiguity for internal concepts
   • For internal commands or domain terms, avoid unclear abbreviations unless the naming/context makes the value’s meaning obvious; prefer descriptive names or add a precise comment that explains the stored value and its unit.

Examples

• Prefer:
  • mem_clients_ref / mem_clients_orphan_ref (but ensure docs/state match inclusion).
  • getClientMemoryUsage() vs getClientOutputBufferMemoryUsage() should clearly state inclusion/exclusion; if needed, rename one to reflect it (e.g., “Size” vs “Usage”).
• Prefer boolean-like naming:
  • int shouldFreeClientAndHandleTimeout(...) over a generic cronHandleClients(...) if the return value drives control flow.
• Enforce case:
  • uint64_t *kvObjMetaRef(...) (function: camelCase).
  • lower_mask (locals: snake_case).

This site is open source. Improve this page.