Chore: ruff rule: N - a sub-issue task of #642

[pygarap]

Steps:

1. Search for the line: ruff.toml -> # "N", # https://docs.astral.sh/ruff/rules/#pep8-naming-n.
2. Uncomment this line.
3. Run just format or just format-concise or just format-grouped.
4. Manually fix any remaining violations.
5. Run just lint or just lint-concise or just lint-grouped.
6. Repeat steps 4–5 until all violations are resolved.

Current [pep8-naming (N)] violations:

• N802 (invalid-function-name): Function names must be lowercase (snake_case)
• N803 (invalid-argument-name): Argument names must be lowercase (snake_case)
• N806 (non-lowercase-variable-in-function): Variables inside functions must be lowercase (snake_case)
• N818 (error-suffix-on-exception-name): Exception class names should end with "Error" (suffix meaning: the ending of a word)
• N999 (invalid-module-name): Module (file) names must be snake_case

[sankarebarri]

Hi @pygarap @pydanny @audreyfeldroy , I enabled rule N locally and got 143 violation, so before proceeding I’d like to clarify a few points so the approach aligns with maintainers’ expectations:

1. Examples vs. Library Naming

Several N802 violations occur in example/demo code (e.g. NavBar, BlogPostPreview, TestComponent).
These follow a component/PascalCase style for readability.

Question: Should these be renamed to snake_case for style purity, or exempt (# noqa: N802 or per-file ignores) to preserve readability?

2. SVG Attribute Names

tags/models/svg.py triggers many N803 violations (e.g. attributeName, preserveAspectRatio).
These mirror literal SVG attribute names.

Question: Should we apply a per-file ignore for N803 here, since renaming diverges from the SVG spec?

3. examples/src/ Filenames

examples/src/*.py triggers N999 due to their structured naming pattern.
These filenames are consumed by copy_src_example_to_callable.py.

Question: Should we add a glob ignore for N999, or is the goal to eventually change the naming scheme?

4. Test Naming Conventions

Some test functions use mixed styles (e.g. test_AirResponse_html) for clarity.

Question: Should these be renamed, or is a small # noqa: N802 acceptable to preserve intent in tests?

5. Constants Inside Tests

Uppercase names inside test functions (e.g. CUSTOM_EXCEPTION_HANDLERS) trigger N806.

Question: Preferred fix:

• move to module-level constants (ALL_CAPS), or
• lowercase locals when they are function-scoped?

6. Public API Naming

Names like BaseAirException and AirField are part of the public API and intentionally capitalized.

Question: Should these be exempted (# noqa) or is renaming them in scope for this rule?

Once clarified, I can proceed.

Thanks!

[pygarap]

@sankarebarri
Hi, thanks for checking this out.

Since enabling N triggers a lot of violations, I would prefer we split this into dedicated PRs, one per rule code, instead of one PR for the whole N prefix. For example: one PR for N802, then N803, then N806, N818, N999. That will make review and rollback much easier.

For the naming conventions themselves, please follow the PEP 8 naming guidance as the default(See: https://pep8.org/#naming-conventions).
Only for special cases where you have a strong reason not to adhere to the PEP 8 naming conventions, please raise it in the PR description (or ask briefly in advance) and we can decide whether to use a per-file ignore.

[sankarebarri]

@sankarebarri Hi, thanks for checking this out.

Since enabling N triggers a lot of violations, I would prefer we split this into dedicated PRs, one per rule code, instead of one PR for the whole N prefix. For example: one PR for N802, then N803, then N806, N818, N999. That will make review and rollback much easier.

For the naming conventions themselves, please follow the PEP 8 naming guidance as the default(See: https://pep8.org/#naming-conventions). Only for special cases where you have a strong reason not to adhere to the PEP 8 naming conventions, please raise it in the PR description (or ask briefly in advance) and we can decide whether to use a per-file ignore.

Perfect, thanks! splitting into PRs by rule code sounds good. Before I start, one quick confirmation:

For cases where adherence to PEP 8 would materially harm readability or API clarity (e.g. SVG literal attribute names, demos, public API), should the default be:

1. # noqa:<rule> on the affected line, or
2. per-file ignore?

Either way works, just want to follow the project’s preference consistently.