clean-codelisted

# Clean Code Principles Apply these principles when writing, reviewing, or refactoring code. They are organized from the most fundamental (naming) to code organization, formatting, and commenting best practices. --- ## 1. Naming & Readability ### 1.1 Avoid Disinformation Never use variable names that create false expectations, contain misleading technical terms, or use visually confusing characters. **Do:** - Use names that honestly reflect the data structure, like `accountsMap` or `accountsGroup`. - Use distinct names for classes/variables so autocomplete doesn't trick you. **Don't:** - Name a map/object `accountList` just because it holds multiple items — to a programmer, "list" means an array/indexed structure. - Create names that vary in tiny ways (e.g., `ABCManagerForEfficientProcessingOfUsers` vs `...PersistingOfUsers`). - Use characters that look identical (e.g., lowercase `l` and number `1`, or uppercase `O` and number `0`). - Bad: `int a = l; if (O == l) a = O1; else l = O1;` Disinformation creates "code lies" where developers' perceptions differ from actual behavior, causing confusion and bugs. ### 1.2 Make Meaningful Distinctions If two things have different names, they must do different things. Avoid meaningless noise words and number series. **Do:** - Reveal the actual role of variables (e.g., `array`, `condition`, `transformation`). - Use specific, role-based names for classes (e.g., `OrderValidator`, `OrderRepository`, `OrderCalculator`). **Don't: