Norminette

When Norminette Is Run

Norm checks are run:

• before commits that touch C headers/sources
• before merging/refactoring milestones
• before final delivery

Typical command used in this project:

norminette include srcs srcs_bonus

For scoped checks during iteration:

norminette <changed_file.c>

Common Violations Encountered

Frequent issues during development:

• function too long
• too many functions in one file
• declaration/order formatting issues
• line length overflow
• spacing/empty-line rule violations
• preprocessor usage in invalid scope
• global variable notices

Typical fix strategy:

• split by responsibility (small focused helpers)
• move shared logic to dedicated module files
• reformat declarations and control-flow blocks
• avoid macro/preprocessor tricks inside function scope

Project-Specific Conventions for Compliance

To stay norm-compliant consistently, this repository follows these conventions:

• one subsystem per folder (parsing, validation, input, render, bonus/*)
• short focused files over oversized multi-purpose files
• explicit helper functions for repeated logic
• no Python/file-generation for C patches; controlled manual edits
• bonus logic isolated in srcs_bonus/ with noop/ compatibility layer
• cleanup and error handling centralized to avoid duplicated long error paths
• pointers reset after destroy/free in shutdown paths when appropriate

Practical Workflow

Recommended routine after edits:

• run norminette on changed files
• run full norminette include srcs srcs_bonus
• compile (make, make bonus)
• run tests (make test, make test_bonus)

This keeps style compliance aligned with functional correctness and avoids late cleanup at the end of the project.