Sample
pyint-ee0e09a8469a-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.004 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 212 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs |
| BTTF | 0.378 | 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. | 13943.051 | −460.121 |
| Source linesThe number of non-empty source lines. | 523 | +209.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.429 | −6.644 |
Intercept 8.87 + feature contributions = -248.694 (log-odds).
Score = sigmoid(-248.694) = 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. | 524 | −17.517 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 392 | +12.822 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 392 | −8.574 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 522.98 | +6.9 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 97.794 | +0.773 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.043 | +0.52 |
| 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. | 97.954 | −0.484 |
Intercept 0.07 + feature contributions = -5.49 (log-odds).
Score = sigmoid(-5.49) = 0.004.
| Score | 0.561 |
|---|
| Score | 212 |
|---|
Run 1
The code is generally readable with clear class structure, logical organization, and good docstrings explaining intent. Import grouping is well-organized. However, it suffers from several readability issues: use of magic numbers (0x1, 0x80, 0x190, etc.) instead of named constants, some deeply nested conditional logic, inconsistent verbosity in comments (very detailed in __init__ but sparse elsewhere), and occasional multi-action lines. The code length is justified by the complexity of a Response class, but some methods could be simplified. Overall, it's maintainable for experienced Python developers familiar with the requests library conventions, but could benefit from extracting magic numbers and simplifying certain control flows.
Run 2
The code is generally well-structured and readable, with clear class organization, type hints, and descriptive docstrings. Imports are grouped logically. Most methods follow a flat structure and perform one action per line. However, some sections reduce readability: the hex constants like 0x1, 0x80, 0x3, 0x190, 0x1f4, and 0x258 obscure intent, and certain methods (e.g., iter_content, json) have moderately deep nesting or complex conditionals. The heavy use of overloads and type annotations, while useful, adds verbosity. Overall, it reads fairly naturally for an experienced Python developer.
Run 3
The code demonstrates strong readability with logical class structure, clear method separation, and comprehensive documentation. The type annotations are extensive and aid understanding. The nesting is shallow with only occasional deeper levels in methods like iter_content. Intent is generally clear through descriptive method names and docstrings, though some methods like __nonzero__ contain duplicated documentation from __bool__. The code is somewhat lengthy due to extensive comments and type annotations, but this improves clarity rather than obscuring it. Action granularity is well-maintained with one primary operation per line. The reading flow is natural, with methods organized logically from initialization through properties and methods. Minor readability concerns include the numerous imports at the top (though well-organized) and occasional use of hexadecimal notation (0x80, 0x1) that may be less immediately clear than decimal equivalents. Overall, the code follows excellent Python conventions and prioritizes clarity through documentation and structure.
Run 1
Code Structure: Cohesive Response class with well-separated methods and properties, though many imports are unrelated to the shown class. Nesting: Mostly shallow, with moderate nesting in streaming and JSON decoding logic. Clarity of intent: Descriptive names, type annotations, and explanatory docstrings help; hexadecimal HTTP status thresholds, chunk sizes, and negative indices unnecessarily obscure familiar values. Content-state sentinels and type-ignore annotations also require extra interpretation. Code length: Generally justified by functionality, but duplicated boolean-method documentation and verbose comments add bulk. Action granularity: Almost consistently one action per line, with a few dense expressions and conditions. Reading flow: Methods follow a sensible progression from initialization to iteration, decoding, error handling, and cleanup; overload declarations and complex line-boundary checks interrupt otherwise natural reading.
Run 2
Code Structure: A cohesive Response class separates initialization, streaming, decoding, status checks, and cleanup into focused methods, though the import block includes many apparently unrelated dependencies. Nesting: Most methods are shallow; streaming and JSON decoding introduce moderate nested branching and exception handling. Clarity of intent: Descriptive names, docstrings, and comments explain behavior well, but hexadecimal literals obscure familiar HTTP status boundaries and indexing, while mixed content sentinels and type suppressions complicate understanding. Code length: Extensive documentation is useful, but repeated boolean-method docstrings, overload declarations, and compatibility machinery make the class lengthy. Action granularity: Statements generally perform one action per line; comprehensions and compound conditions remain mostly manageable. Reading flow: Methods follow a sensible progression from object lifecycle to response access and cleanup. However, implicit content consumption through property access, dense line-buffer logic, and names not defined in the supplied snippet interrupt otherwise natural reading.
Run 3
Code Structure: Well-organized class with focused methods and properties separating response handling concerns. Nesting: Mostly shallow, though streaming and JSON decoding contain moderately nested branches and exception handling. Clarity of intent: Descriptive names, annotations, and extensive documentation help, but hexadecimal HTTP status codes and indices obscure familiar values; mixed sentinel states and type-ignore comments complicate understanding. Code length: Generally justified by functionality, but repeated docstrings, lengthy comments, overloads, and numerous imports add reading overhead. Action granularity: Consistently uses one main action per line, with only a few dense expressions such as the pending-line condition. Reading flow: Methods follow a coherent progression from initialization to streaming, decoding, validation, and cleanup. However, external names not defined in the snippet and stateful interactions between content consumption and iteration require additional context.