Names should accurately reflect the actual behavior, purpose, and scope of functions, variables, and classes. Misleading or inaccurate names create confusion and maintenance burden.
Names should accurately reflect the actual behavior, purpose, and scope of functions, variables, and classes. Misleading or inaccurate names create confusion and maintenance burden.
Key principles:
Examples of improvements:
;; Bad: Name suggests uniqueness per view but acts like a type
:logseq.property.view/identity
;; Good: Accurately describes what it represents
:logseq.property/ui-type
;; Bad: Overly specific, requires changes when extended
:logseq.property/checkbox-default-value
;; Good: Generic enough to support other non-ref types
:logseq.property/scalar-default-value
;; Bad: Ambiguous abbreviation
[frontend.encrypt :as e] ; could be event, error, etc.
;; Good: Clear and unambiguous
[frontend.encrypt :as encrypt]
;; Bad: Predicate naming convention but returns a key
(defn block-or-page? [id] ...)
;; Good: Either follow predicate convention or use descriptive name
(defn block-or-page-type [id] ...)
This prevents bugs caused by incorrect assumptions about functionality and makes code self-documenting for future maintainers.
Enter the URL of a public GitHub repository