Sample
pyint-66c9d3ff9c93-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.988 | 0–1; higher is more readable |
| Dorn | 0.278 | 0–1; higher is more readable |
| Mi | 0.77 | 0–1; higher is more readable |
| LLOC | 56 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 8.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.631 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 189 | +75.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 2222.559 | −73.344 |
| 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.491 | −6.736 |
Intercept 8.87 + feature contributions = 4.389 (log-odds).
Score = sigmoid(4.389) = 0.988.
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. | 190 | −5.691 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 114 | +3.206 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 188.963 | +2.232 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 114 | −2.195 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.024 | +0.709 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 79.3 | +0.475 |
| 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. | 80.926 | +0.238 |
Intercept 0.07 + feature contributions = -0.956 (log-odds).
Score = sigmoid(-0.956) = 0.278.
| Score | 0.77 |
|---|
| Score | 56 |
|---|
Run 1
The code has clear documentation, type hints, and logical organization, but the __init__ method uses opaque parameter names (is3, is4, has, added2, etc.) that don't match the documented attributes. This makes it very hard to understand what each argument represents without cross-referencing the __slots__ order. Additionally, the property 'is2' has a non-descriptive name. These choices significantly hurt clarity of intent and reading flow.
Run 2
The code has good documentation and type hints, making intent fairly clear. However, it suffers from severe readability issues: the __init__ method uses cryptic parameter names (is3, is4, has, is5, added2, has2, etc.) that don't map clearly to their attributes. Action granularity is poor, as each line sets one attribute but with confusing names. The nested enums add some structure, but the overall reading flow is disrupted by inconsistent naming and unclear parameter semantics. The __slots__ declaration with RUF023 comment shows awareness of ordering but doesn't help readability. While the class documentation is thorough, the code itself requires constant cross-referencing between parameters and attributes, making it ambiguous and difficult to follow.
Run 3
The code has some good structure (nested enums, single class with documented attributes), but readability is severely hurt by poor naming and lack of clear intent. The '__init__' parameters are cryptic and nondescript (is3, is4, has, is5, added2, etc.) which makes it impossible to understand what each argument represents without cross-referencing the class slots. This forces readers to map numbers to attributes manually. The property 'is2' is also ambiguous. The flat-ish structure and one-action-per-line in '__init__' help slightly, but the code is unnecessarily obscure due to those names. Docstrings are helpful, but the implementation fails to mirror their clarity. Overall, not terrible to skim if you ignore the constructor, but painful to work with or maintain.
Run 1
Code Structure: Logically organized into documentation, nested enums, slots, initialization, and a property. Nesting: Shallow and easy to follow; nested enums appropriately group related concepts. Clarity of intent: Descriptive attributes and thorough documentation explain the data model, but constructor parameters such as is3, added4, and has2 obscure their meanings. The property name is2 also fails to communicate its purpose. Code length: Most length comes from useful documentation, though the large constructor and repetitive assignments increase scanning effort. Action granularity: Each assignment and enum definition performs one action per line. Reading flow: Consistent formatting and sequential assignments support natural reading, but readers must repeatedly map ambiguous parameters to meaningful attributes. Overall, the structure is readable, while poor parameter and property naming substantially weakens comprehension.
Run 2
Code Structure: Logically organized into a documented class, nested enums, slots, initialization, and a property. Nesting: Shallow and easy to follow; nested enums are appropriate. Clarity of intent: Descriptive attributes and extensive documentation help, but constructor parameters such as is3, added4, and has2 obscure their meanings, and the property name is2 hides its purpose. Code length: The documentation is useful but dominates this small implementation; numerous imports are unused within the snippet, and repetitive initialization adds bulk. Action granularity: Assignments and enum definitions generally perform one action per line, making individual statements easy to scan. Reading flow: The class follows a natural progression, but readers must repeatedly map ambiguous constructor parameters to descriptive attributes, disrupting comprehension.
Run 3
Code Structure: Logically organized into a documented class, nested enums, slots, initialization, and a property. Nesting: Shallow and appropriate, with no complex control flow. Clarity of intent: Descriptive attribute names and extensive documentation help, but cryptic constructor parameters such as is3, added4, and has2 obscure their meanings; the property name is2 hides its hashability check. Code length: Straightforward implementation, but lengthy documentation and repetitive declarations make this simple data container cumbersome to scan. Action granularity: Each assignment occupies its own line, and enum definitions are clearly separated. Reading flow: The overall progression is natural, but readers must repeatedly map ambiguous parameters to documented attributes, significantly interrupting comprehension.