Sample
pyint-81030b1f9317-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.334 | 0–1; higher is more readable |
| Mi | 0.738 | 0–1; higher is more readable |
| LLOC | 61 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.67 | 0–20; mean of three runs |
| BTTF | 0.467 | 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. | 3948.607 | −130.304 |
| Source linesThe number of non-empty source lines. | 198 | +79.2 |
| 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.044 | −6.066 |
Intercept 8.87 + feature contributions = -48.3 (log-odds).
Score = sigmoid(-48.3) = 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. | 199 | −6.01 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 171 | +5.178 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 171 | −3.503 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 197.974 | +2.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.421 |
| 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. | 76.985 | +0.404 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74.271 | +0.394 |
Intercept 0.07 + feature contributions = -0.688 (log-odds).
Score = sigmoid(-0.688) = 0.334.
| Score | 0.738 |
|---|
| Score | 61 |
|---|
Run 1
The code has moderate readability. It shows good organization with clear imports, docstrings, and a logical class structure. The __attrs_attrs__ declaration, while complex, follows a consistent pattern. However, several issues reduce readability: the __init__ method has 17 positional parameters, making it prone to errors and difficult to understand without reading the full signature. The __attrs_attrs__ tuple construction uses a generator expression with deeply nested Attribute calls, creating visual complexity. The default() method contains unrelated dead code (a loop summing 1-5 that serves no purpose), which obscures intent. Method names are clear, but the heavy use of leading underscores and internal naming conventions assumes familiarity with the attrs library internals. The code is relatively flat, which helps nesting, but the parameter density and repetitive Attribute constructor calls reduce scanability. Overall, the code is structured and documented but burdened by excessive parameters and dense initialization patterns.
Run 2
The code has clear structure with logical organization, but it includes unexplained dead code (the running_total loop in default()), making intent unclear. Long __init__ and __attrs_attrs__ definitions reduce readability. Mixed item grouping and line length hinder natural flow.
Run 3
The code demonstrates mostly clear organization with appropriate imports, docstrings, and consistent naming. However, readability suffers in several areas: the __attrs_attrs__ construction is overly complex with deeply nested tuple generation and a very long Attribute instantiation repeated many times, making it difficult to scan. The __init__ method has an extremely long parameter list without type hints, obscuring intent. Some methods like default() contain unrelated loop code that doesn't match its purpose, creating confusion. While the code generally follows one-action-per-line and uses flat rather than deeply nested logic, the repetitive verbose Attribute definitions and large parameter counts reduce clarity. The use of slots and cached properties is good practice but adds cognitive load. Overall structure is logical for a library internals file, but the density of configuration-heavy code makes it harder to read than necessary.
Run 1
Code Structure: The class is logically organized into attribute metadata, initialization, and decorator methods, though extensive setup adds bulk. Nesting: Mostly flat, with only shallow conditionals, a loop, and a comprehension. Clarity of intent: Descriptive names and docstrings explain ordering and decorator behavior; however, the unused running_total calculation is unrelated to setting defaults and distracts from intent. Code length: Repeated Attribute arguments, numerous imports, and the long constructor increase reading effort, although much of the verbosity supports explicit configuration. Action granularity: Assignments and operations generally occupy separate lines; the converter lambda remains compact and understandable. Reading flow: Consistent formatting and straightforward methods support natural reading, but externally defined helpers and constants require surrounding context, and the irrelevant loop interrupts the default method.
Run 2
Code Structure: The class is logically organized into attribute declarations, initialization, and focused decorator methods, although the large import block adds clutter. Nesting: Control flow is shallow; the attribute-generation expression is denser but manageable. Clarity of intent: Descriptive names and docstrings explain the class and methods well, but the unused running_total calculation in default() is unrelated and distracting. Code length: Repeated Attribute configuration and the long constructor make the code verbose, while the extraneous loop adds unnecessary length. Action granularity: Statements generally perform one action per line, making assignments and state changes easy to follow. Reading flow: Consistent formatting and straightforward method bodies support natural reading, but the lengthy class-level metadata and references to definitions outside the snippet require additional context.
Run 3
Code Structure: Logically organized around one class, with attribute declarations, initialization, and decorator methods clearly separated. Nesting: Mostly flat; the metadata comprehension and converter lambda add modest complexity. Clarity of intent: Descriptive method names and docstrings explain behavior, but external helpers require context, and the unused running_total loop obscures the default method's purpose. Code length: Repetitive Attribute configuration, a long constructor, and numerous imports make the snippet verbose; the irrelevant loop adds unnecessary length. Action granularity: Statements generally perform one action per line, with consistently formatted multiline calls. Reading flow: Methods follow predictable patterns and are easy to scan, although extensive setup delays the behavioral code, and names such as repr, hash, and type shadow built-ins.