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