Sample
pyint-24a602729be6-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.346 | 0–1; higher is more readable |
| Mi | 0.738 | 0–1; higher is more readable |
| LLOC | 58 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.462 | 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. | 3811.44 | −125.778 |
| Source linesThe number of non-empty source lines. | 195 | +78 |
| 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.042 | −6.064 |
Intercept 8.87 + feature contributions = -44.971 (log-odds).
Score = sigmoid(-44.971) = 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. | 196 | −5.903 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 168 | +5.074 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 168 | −3.434 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 194.987 | +2.316 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.424 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 75.342 | +0.411 |
| 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.949 | +0.406 |
Intercept 0.07 + feature contributions = -0.637 (log-odds).
Score = sigmoid(-0.637) = 0.346.
| Score | 0.738 |
|---|
| Score | 58 |
|---|
Run 1
The code is moderately readable. It demonstrates good structural organization with clear separation of concerns, documentation strings, and use of slots. However, the massive __attrs_attrs__ tuple with nested Attribute constructors creates a deeply complex initialization block that is hard to parse. The constructor has 16 parameters, making it difficult to understand the data model at a glance. While naming is descriptive and imports are organized, the action granularity is poor in places - the tuple building spans dozens of lines with what is essentially a single logical action. The counter increment using hex values (0x1) is unnecessarily obscure. Reading flow is disrupted by the generated-looking attribute definitions in the middle of the class. Overall, the individual methods are clear, but the class-level data structure definition significantly reduces readability.
Run 2
The code is challenging to read due to its dense, highly technical nature and unusual style. While it demonstrates logical organization through the use of slots, counters, and docstrings, the structure is undermined by deeply nested and repetitive initialization code within `__attrs_attrs__`. The `__init__` method has a very long parameter list, affecting readability. The intent is somewhat clear for experienced library developers, but the domain-specific naming (e.g., `eq_key`, `kw_only`) and internal comments make it inaccessible to others. The code length is excessive for the functionality shown, especially the verbose attribute definitions. Action granularity is mostly one action per line, but the sheer volume of parameter assignments and the nested tuple comprehension reduce clarity. The reading flow is disorganized due to the abrupt shift from imports to complex class-level data structures. Overall, it appears functional but requires deep domain knowledge to parse effectively.
Run 3
The code is moderately readable. It uses clear naming, type hints, and docstrings, which help with intent. The structure is logical, with the class and its methods organized into coherent sections. However, readability is hurt by the very long __attrs_attrs__ tuple with a generator expression and a repeated 16-argument constructor call, making that section dense and hard to parse. The __init__ method also has many parameters but is straightforward. Nesting is mostly flat, but the long tuple construction adds visual complexity. Code length is reasonable, though some parts feel verbose due to the project's internal requirements. Action granularity is generally one action per line. Reading flow is natural for the most part, but the large attribute metadata block interrupts the flow. Overall, it is understandable for an experienced developer familiar with the library but not beginner-friendly.
Run 1
Code Structure: The class is logically organized into metadata, initialization, and decorator methods, although the large metadata declaration dominates the opening. Nesting: Control flow is shallow; the nested tuple expansion and comprehension are somewhat harder to scan. Clarity of intent: The class and method docstrings clearly explain their purposes, and most names are descriptive. External helpers and built-in-shadowing parameter names require additional context. Code length: Repeated Attribute configuration and the long constructor add verbosity, though much of it reflects the data model. Action granularity: Statements generally perform one action per line, making assignments and state changes easy to follow. Reading flow: Methods proceed naturally from checks to updates to returns, but lengthy declarations, numerous imports, and unconventional hexadecimal counter values introduce minor distractions.
Run 2
Code Structure: Logically organized into a documented class, attribute declarations, initialization, and focused decorator methods. Nesting: Mostly flat, with simple conditionals; the expanded comprehension in __attrs_attrs__ is harder to scan. Clarity of intent: Descriptive names and docstrings explain ordering and decorator behavior, although external helpers and metadata conventions require context. Code length: Long argument lists, repetitive Attribute configurations, and many imports not used in this excerpt add visual overhead. Action granularity: Assignments and operations generally occupy separate lines, making individual steps easy to follow. Reading flow: Methods follow a consistent, natural pattern, but extensive setup delays the behavioral code. Built-in-shadowing parameter names and hexadecimal counter literals slightly reduce readability.
Run 3
Code Structure: Logically organized around a single class, with configuration, initialization, and decorator methods clearly separated. Nesting: Mostly flat; the attribute-building comprehension and converter wrapper add limited complexity. Clarity of intent: The class docstring and method documentation explain purpose well, although external helpers, framework-specific metadata, built-in-shadowing parameter names, and hexadecimal counter literals require extra interpretation. Code length: Repetitive Attribute configuration and a large constructor make the code verbose, while many imports are unused within this excerpt. Action granularity: Assignments and state changes generally occupy individual lines, making operations easy to follow. Reading flow: Consistent formatting and straightforward methods support natural reading, but the lengthy metadata declaration delays the main behavior and increases cognitive load.