Sample
pyint-549c5b3ccd1f-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.105 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 73 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.445 | 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. | 5522.817 | −182.253 |
| Source linesThe number of non-empty source lines. | 270 | +108 |
| 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.383 | −6.575 |
Intercept 8.87 + feature contributions = -71.958 (log-odds).
Score = sigmoid(-71.958) = 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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 196 | +6.042 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.957 | +3.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.978 | +0.663 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.541 |
| 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. | 90.956 | −0.187 |
Intercept 0.07 + feature contributions = -2.143 (log-odds).
Score = sigmoid(-2.143) = 0.105.
| Score | 0.583 |
|---|
| Score | 73 |
|---|
Run 1
The code is moderately readable. It has clear structure with a well-documented class, logical method organization, and good use of slots/type hints. However, it loses points due to long methods with many steps (__init__, evolve), repetitive bound_setattr calls that add vertical length without clarity, and some magic/complex conditional logic (alias_is_default handling). Nesting is generally flat, and intent is mostly clear, but the alias/alias_is_default interactions are subtle and not self-explanatory. The class docstring is thorough but very long. Action granularity is mostly one-per-line, which aids readability, but some lines pack multiple operations. Overall, it reads like mature library code with historical baggage; readable for maintainers but not immediately accessible to newcomers.
Run 2
The code is structurally clear at the class level and has helpful docstrings, but readability is severely hampered by heavy low-level machinery and inconsistent abstraction. The __init__ method relies on repeated bound_setattr calls and magic descriptors like _OBJ_SETATTR, making the simple act of setting fields obscure. Many parameters are positional, including a comment noting one is unused, which adds cognitive overhead. The nested conditional logic in evolve and __setstate__ is not deeply indented but is difficult to follow due to reliance on internal state manipulation, zip trickery, and special-case handling. The module-level imports include several unused or conditional names, further muddying intent. While the code is dense and avoids excessive length, the one-action-per-line style actually works against clarity here because the operations are non-obvious. Overall, the code requires deep familiarity with the library’s internals to read confidently, making it accessible mainly to maintainers rather than general readers.
Run 3
The code demonstrates strong readability overall. Structure is logical: imports are organized, the class has a clear purpose, and methods are grouped meaningfully. Nesting is minimal—only a few conditional blocks exist, none deeply nested. Intent is clearly expressed through descriptive names (e.g., `from_counting_attr`, `alias_is_default`, `FrozenInstanceError`) and helpful docstrings with version history and warnings. Action granularity is mostly good, with one primary operation per line, though some lines like `bound_setattr('alias_is_default', alias is None if alias_is_default is None else alias_is_default)` combine logic. Length is reasonable—comprehensive but not bloated for the complexity the class represents. Reading flow is natural: the constructor progresses logically through attribute initialization, and the pickle/evolve methods are separated appropriately. Minor deductions: the `cmp` parameter marked unused is slightly confusing, some conditional expressions could be clearer, and the `_setattrs` method is concise but perhaps too terse without visible context. Overall, this is clean library code that balances documentation with implementation effectively.
Run 1
Code Structure: Methods are logically grouped around initialization, copying, serialization, and immutable attribute handling. Nesting: Mostly flat, with shallow conditionals and loops; multiline expressions add some visual complexity. Clarity of intent: Descriptive method names, extensive documentation, and explanatory comments make responsibilities clear, although private helpers and descriptor manipulation require background knowledge. Code length: Generally justified, but the lengthy documentation, repeated assignments, and large constructor increase reading effort. Action granularity: Most lines perform one action; tuple unpacking and conditional expressions remain reasonably focused. Reading flow: Consistent formatting and method organization support natural reading, but the long positional constructor call requires matching arguments manually, and slot-order dependencies plus awkwardly wrapped serialization logic interrupt the flow.
Run 2
Code Structure: Cohesive class with clearly separated initialization, copying, serialization, and internal assignment methods. Nesting: Mostly shallow; conditional expressions and multiline conditions add modest complexity. Clarity of intent: Descriptive method names, extensive documentation, and helpful comments explain behavior, though descriptor manipulation, external helpers, and the long positional constructor call require careful interpretation. Code length: Generally justified, but repetitive assignments, lengthy documentation, and compatibility handling increase reading effort. Action granularity: Operations are predominantly one per line, with clear separation between steps. Reading flow: Methods follow a logical sequence, but lengthy parameter lists, order-dependent slots, and awkward wrapping in pickle compatibility logic interrupt otherwise natural flow.
Run 3
Code Structure: Well-organized class with distinct initialization, construction, copying, and serialization methods. Nesting: Mostly shallow; conditional expressions and multiline calls add some visual complexity without deep nesting. Clarity of intent: Descriptive methods, extensive documentation, and explanatory comments clarify immutability and compatibility behavior. However, external helpers, abbreviated names such as ca, and the long positional constructor call require additional context. Code length: Generally justified, although lengthy documentation, repeated assignments, and duplicated metadata conversion make the excerpt verbose. Action granularity: Statements generally perform one action per line; tuple unpacking and conditional expressions remain manageable. Reading flow: Methods follow a sensible progression, but the large parameter list, order-sensitive slots, and awkward wrapping in pickle compatibility logic interrupt scanning.