|
| 1 | +# ASTx Code Styling and Conventions |
| 2 | + |
| 3 | +This document outlines the coding standards and conventions for the ASTx |
| 4 | +project. Following these guidelines ensures consistency, readability, and |
| 5 | +maintainability across the codebase. |
| 6 | + |
| 7 | +## General Guidelines |
| 8 | + |
| 9 | +- **Type Safety:** Always use the `@typechecked` decorator on all new ASTx |
| 10 | + classes to enforce runtime type checks. Additionally, do not reuse a variable |
| 11 | + for different types within the same context. |
| 12 | + |
| 13 | +- **Reference Existing Syntax:** When implementing an ASTx class that |
| 14 | + corresponds to a Python syntax construct, refer to Python’s AST (e.g., using |
| 15 | + `ast.dump(ast.parse("class MyClass:\n attr1: int = 1"))`) to validate that all |
| 16 | + necessary attributes and subnodes are correctly implemented. |
| 17 | + |
| 18 | +- **Avoid Excessive Nesting:** Follow the "never nesting" approach to reduce |
| 19 | + code complexity. Review resources such as |
| 20 | + [Never Nester – Why You Shouldn’t Nest Your Code](https://buildfactory.dk/never-nester-why-you-shouldnt-nest-your-code/) |
| 21 | + and |
| 22 | + [How and Why to Avoid Excessive Nesting](https://www.codeproject.com/Articles/626403/How-and-Why-to-Avoid-Excessive-Nesting). |
| 23 | + |
| 24 | +## **str** Method Conventions |
| 25 | + |
| 26 | +- **Class Name:** The `__str__` method of an ASTx node should return the name of |
| 27 | + the class in CapitalizedCamelCase. |
| 28 | + |
| 29 | +- **Attributes Representation:** |
| 30 | + - If a node has one attribute (that is not another ASTx node), display it in |
| 31 | + square brackets immediately after the class name. _Example:_ |
| 32 | + `LiteralInt32[1]` |
| 33 | + - If a node has multiple non-ASTx attributes, list them with the attribute |
| 34 | + name(s) and value(s) separated by commas. _Example:_ |
| 35 | + `LiteralComplex32[real=1, imag=1]` |
| 36 | + - For boolean attributes, you may: |
| 37 | + - Include the attribute name if its value is `True` (e.g., |
| 38 | + `Class[abstract]`), omitting it if `False`. |
| 39 | + - Alternatively, differentiate using distinct names (e.g., `Class[static]` |
| 40 | + vs. `Class[non-static]`), as appropriate for the specific node. |
| 41 | + |
| 42 | +## get_struct Method Conventions |
| 43 | + |
| 44 | +- **Naming Consistency:** The key in the `get_struct` output should match the |
| 45 | + string returned by the node’s `__str__` method. When the `simplified` flag is |
| 46 | + `True`, append `#{id(self)}` to the name to prevent grouping in ASCII |
| 47 | + representations. |
| 48 | + |
| 49 | +- **Sub-node Keys:** Each sub-node in the structure should be represented with a |
| 50 | + key in lowercase using hyphen separators. _Example:_ |
| 51 | + ```python |
| 52 | + { |
| 53 | + "except": except_.get_struct(simplified), |
| 54 | + "finally-handler": finally_handler.get_struct(simplified) |
| 55 | + } |
| 56 | + ``` |
0 commit comments