Sample
pyint-557c4dac856c-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.002 | 0–1; higher is more readable |
| Mi | 0.712 | 0–1; higher is more readable |
| LLOC | 281 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.308 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 21338.366 | −704.166 |
| Source linesThe number of non-empty source lines. | 614 | +245.6 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 4.045 | −6.068 |
Intercept 8.87 + feature contributions = -455.764 (log-odds).
Score = sigmoid(-455.764) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 615 | −20.739 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 614 | +20.5 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 614 | −13.669 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 613.894 | +8.171 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 92.966 | −0.272 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.069 | +0.269 |
Intercept 0.07 + feature contributions = -6.474 (log-odds).
Score = sigmoid(-6.474) = 0.002.
| Score | 0.712 |
|---|
| Score | 281 |
|---|
Run 1
The code is generally well-structured with clear class organization, logical method grouping, and consistent naming. It uses meaningful variable names, type hints, and docstrings that aid understanding. However, it has several readability challenges: high nesting in methods like _create_slots_class and add_setattr, long parameter lists, and complex conditionals that require careful reading. Some methods mix multiple responsibilities and the flow jumps between setup logic and conditional branches. The code is readable for experienced Python developers familiar with metaclasses but would be challenging for those without deep understanding of Python's class internals.
Run 2
The code is organized into a single large class with logical method separation, but several methods are excessively long (_create_slots_class, __init__, add_setattr) and contain deeply nested conditionals. Nesting reaches 3-4 levels with multiple boolean checks and loops, making control flow hard to follow. Intent is often unclear due to sparse comments that explain 'why' but not 'what' the complex conditional branches are doing. Code length is unnecessarily verbose - many methods could be extracted or simplified. Action granularity is mostly good with one operation per line, but some lines combine multiple comprehensions or conditional expressions. Reading flow is disrupted by heavy use of dunder methods, magic strings, and framework-specific patterns (closure cell manipulation, type reconstruction) that assume deep familiarity with Python internals and the attrs library. The __slots__ declaration, though long, does aid comprehension. Overall, the code demonstrates domain complexity but lacks refactoring into smaller, self-documenting units, and would benefit from clearer variable names and more explanatory comments for the metaclass machinery.
Run 3
The code shows significant readability issues: it's extremely long (700+ lines), has deeply nested methods (especially _create_slots_class with 6+ levels of indentation), and mixes multiple responsibilities within single methods. The _ClassBuilder class manages class construction, slot creation, method generation, and attribute handling simultaneously, making the logic tangled. Method names like _make_getstate_setstate and _add_method_dunders_unsafe are somewhat cryptic without deep attrs library context. The heavy use of private attributes (leading underscores) obscures the state management flow. While there are some good practices like docstrings, type hints, and comments explaining complex sections, the overall structure remains dense and difficult to follow. The action granularity is inconsistent - some lines pack multiple operations while others are appropriately separated. The caching property extraction logic, closure cell manipulation, and conditional branches create spaghetti-like flow that requires significant mental overhead to trace.
Run 1
Code Structure: Well-organized builder class with focused method-generation helpers, but initialization and slot creation combine many responsibilities. Nesting: Most methods are shallow; slot creation, closure updates, and setter hooks introduce several nested branches and loops. Clarity of intent: Descriptive method names communicate the overall purpose, but abbreviations such as cd, sa_attrs, and nval, extensive internal state, and undocumented metaprogramming details obscure implementation intent. Code length: Some complexity is justified, but duplicated initialization-generation methods, repeated metadata assignments, and excessive blank lines make the code longer than necessary. Action granularity: Most statements perform one action, although chained assignments and simultaneous assignment of multiple generated methods are denser. Reading flow: Consistent formatting and helper boundaries support navigation, while long conditions, numerous configuration flags, deferred script execution, and closure manipulation require substantial cross-referencing.
Run 2
Code Structure: Cohesive builder class with clearly separated method-generation and class-construction helpers, though initialization and slot creation handle many responsibilities. Nesting: Mostly moderate, but inheritance handling, closure updates, and setter hooks introduce deeper branches. Clarity of intent: Descriptive method names and state fields communicate the broad purpose; abbreviated locals, metaprogramming details, and absent explanatory comments obscure subtleties. Code length: Much complexity appears justified, but duplicated initialization-generation and metadata-setting logic, long methods, and excessive blank lines reduce concision. Action granularity: Generally one operation per line, with occasional chained or multi-target assignments that slightly increase reading effort. Reading flow: Consistent builder patterns and sequential processing help navigation, but numerous flags, deferred script execution, closures, and external helpers require readers to track substantial context.
Run 3
Code Structure: Cohesive builder class with well-separated method-generation operations, but initialization and slot creation combine many responsibilities. Nesting: Mostly moderate, with deeper loops, conditionals, and exception handling in closure updates and setter hooks. Clarity of intent: Descriptive method and field names communicate the overall purpose; missing explanatory comments/docstrings, abbreviated locals, and intricate metaprogramming obscure important details. Code length: Small helper methods are concise, but lengthy initialization and slot construction, duplicated init-generation logic, and excessive blank lines increase reading effort. Action granularity: Generally one action per line, with occasional chained assignments and multi-target unpacking adding density. Reading flow: The builder lifecycle and repeated attachment pattern are reasonably natural, but numerous state flags, external helpers, nested callbacks, and dynamic class modifications require substantial cross-referencing.