I follow this guide to ensure that all Python 3 code I write for Fossil Logic is clean, readable, and maintainable, supporting collaboration and long-term project quality.

1. General Principles

• I write code that is clear and self-explanatory.
• I follow PEP 8 conventions unless project-specific rules require exceptions.
• I document non-obvious logic with concise, meaningful comments.

2. File and Module Structure

• I include a header comment explaining the module’s purpose, author, and creation date.
• I organize imports in three sections, separated by blank lines:
  1. Standard library imports.
  2. Third-party library imports.
  3. Project-specific imports.
• I avoid wildcard imports (from module import *).

3. Naming Conventions

• I use snake_case for variables and functions.
• I use PascalCase for classes.
• I use UPPERCASE_WITH_UNDERSCORES for constants.
• Names are descriptive and avoid ambiguous abbreviations.

4. Indentation and Formatting

• I use 4 spaces per indentation level; tabs are not used.
• I limit lines to 79–100 characters.
• I use blank lines to separate top-level functions, classes, and logical code sections.

5. Functions and Methods

• I keep functions focused and ideally under 50 lines.
• I use default arguments carefully and avoid mutable defaults.
• I document functions using docstrings, describing parameters, return values, and exceptions.
• I prefer keyword arguments for clarity in function calls when possible.

6. Classes and Objects

• I group public, protected, and private members logically.
• I use properties (@property) instead of direct attribute access when appropriate.
• I document classes and their methods with docstrings explaining behavior and usage.
• I follow composition over inheritance unless clear benefits exist for using inheritance.

7. Control Structures

• I always use clear, explicit control structures (if, for, while).
• I avoid deeply nested blocks; I prefer early returns and helper functions.
• I use list comprehensions and generator expressions for clarity and efficiency when appropriate.

8. Exception Handling

• I use exceptions for error handling and document which exceptions a function may raise.
• I avoid bare except: statements; I catch specific exceptions.
• I log errors or propagate exceptions as appropriate for maintainability and debugging.

9. Type Hints and Annotations

• I use type hints for function parameters and return values for clarity and static analysis.
• I maintain consistency in annotation style across modules.

10. Comments and Documentation

• I write comments to explain why something is done, not what.
• I maintain consistent style for inline and block comments.
• I update comments and docstrings whenever code is changed.

11. Testing and Debugging

• I write modular, testable code.
• I use unittest, pytest, or project-approved testing frameworks consistently.
• I include assertions and logging for critical assumptions.
• I remove temporary debug code before committing, keeping optional debug flags if necessary.

12. Version Control Practices

• I ensure code passes tests and lints cleanly before committing.
• I write descriptive commit messages explaining what and why.
• I follow project conventions consistently to reduce merge conflicts.