Shop Project - Documentation

General Naming Rules

• Short but Clear: As short as possible, as clear as necessary for immediate understanding.
• One Concept, One Name: Once a domain term is established (e.g., Label, Order, User), it is used consistently project-wide without switching to synonyms.
• Standardized Identifiers: Abbreviations are used exclusively when defined in the project glossary and known project-wide.
• English in Code: All identifiers, variables, functions, and code comments are strictly written in English.

Variable and Function Names

• Casing: camelCase for variables and functions ($labelData, handleUpdate()), UPPER_SNAKE_CASE for constants (cCg::DEFAULT_PSW).
• Verbs for Actions & Functions: Function names start with precise standard verbs (e.g., get, set, handle, check, export, load).
• Nouns for Data & Objects: Data containers and objects are named as meaningful nouns (routeConfig, navContext).
• Boolean States: Booleans are phrased as clear state statements with prefixes (isOpen, hasAccess, canEdit).
• Variant Naming: Variations of the same base data retain the base name at the front and append the suffix at the end (e.g., $labelData → $labelDataFiltered → $labelDataExport).
• Local Loop Counters: Short counters like $i or $idx are permitted strictly inside tight, local loops.

System Prefixes & Class Abbreviations

Configuration and system classes that primarily group constants are intentionally kept very short to enhance readability:

• c as a prefix for central system & configuration classes (e.g., cCg for Core Configuration, cSession for the Session class, cApp for the Application).

Note: All abbreviated system classes (cCg, cSc, cFc, etc.) must be fully documented in the central project glossary and their respective class doc-blocks.

Classes, Files, and Modules

• Class Names as Domain Objects: Classes represent clear entities or services (e.g., AccessService, NavModel, LabelController).
• Role-Based File Names: File names indicate their architectural role via suffix (*.service.php, *.model.php, *.view.php, *.controller.php).
• Responsibility-Driven Modules: Module and folder names reflect their domain purpose (e.g., navigation, label-management), not technical details.

Review Checklist

• Does a new developer immediately grasp the purpose of the name without extra context?
• Is the name as short as possible without losing precise meaning?
• Is the same domain term used identically across related files?
• Do variants follow the pattern BaseName + Suffix (e.g., $labelDataFiltered)?