Sample
pyint-0fdda1a48b80-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.078 | 0–1; higher is more readable |
| Mi | 0.572 | 0–1; higher is more readable |
| LLOC | 160 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.291 | 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. | 9921.788 | −327.419 |
| Source linesThe number of non-empty source lines. | 245 | +98 |
| 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.51 | −6.765 |
Intercept 8.87 + feature contributions = -227.314 (log-odds).
Score = sigmoid(-227.314) = 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. | 246 | −7.674 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 219 | +6.838 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 219 | −4.605 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 244.829 | +3.012 |
| 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. | 121.984 | −1.502 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.992 | +1.164 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.224 |
Intercept 0.07 + feature contributions = -2.472 (log-odds).
Score = sigmoid(-2.472) = 0.078.
| Score | 0.572 |
|---|
| Score | 160 |
|---|
Run 1
The code has a clear class structure and docstrings, which helps intent. However, the build_digest_header method is very long with multiple nested logic branches and duplicated near-identical nested function definitions for hash algorithms, reducing readability. Use of hex literals like 0x190 instead of 400 hurts clarity. Many comments are helpful, but 'XXX not implemented yet' indicates unfinished logic. The code occasionally crams multiple related operations per line (e.g., string concatenations with assignments). The __eq__ method uses list of comparisons instead of tuple or straightforward and, adding slight noise. Per-thread state access is repeated heavily, making lines long. Overall, the code is functional and organized but could be significantly clearer with shorter functions, helper methods, dictionary lookups for algorithm handlers, and decimal status constants.
Run 2
The code is generally well-structured with clear class organization, type hints, and docstrings, but several factors reduce readability. The build_digest_header method is very long and contains deeply nested conditional logic with multiple inner functions, making it harder to follow the flow. The heavy use of hexadecimal literals (0x1, 0x2, 0x190, etc.) for simple values like counters and status codes obscures intent—standard decimal notation would be clearer. Some variables have cryptic names (KD, A1, A2, HA1) that require RFC knowledge to understand. The anonymous inner functions for hashing algorithms add length and repetition that could be consolidated. Comments use 'XXX' markers indicating unfinished work. However, the per-thread state pattern is clearly documented, type annotations improve clarity, and method responsibilities are logically separated. The overall reading flow is adequate but interrupted by dense algorithm implementation details that could be extracted.
Run 3
The code is structured with clear class/method separation and comments, but readability suffers from several issues. Digest algorithm selection uses nested conditional logic with repeated lambda definitions, making the flow cluttered. Magic numbers (0x190, 0x1f4, 0x2, etc.) obscure intent. The method `build_digest_header` is long and handles multiple concerns (parsing URL, algorithm selection, hashing, header construction). While type hints and docstrings help, the heavy use of `_thread_local` throughout adds visual noise and obscures the auth state model. Variable names like `KD`, `HA1`, `A2` follow RFC terminology but remain cryptic without context. Some parts, like `handle_401`, are reasonably linear but still mix concerns. Overall, the code is readable for those familiar with HTTP Digest auth, but could benefit from refactoring algorithm selection into separate functions and replacing numeric literals with named constants.
Run 1
Code Structure: Methods logically separate initialization, digest construction, response handling, and comparison, but digest construction combines several responsibilities. Nesting: Mostly shallow conditionals and early returns keep complexity manageable; nested hashing functions add some depth. Clarity of intent: Descriptive method names, annotations, and explanatory comments help, while abbreviated variables, hexadecimal counters/status codes, stale comments, and undeclared dependencies obscure details. Code length: Repeated hashing wrappers and verbose thread-local access make the implementation longer than necessary. Action granularity: Nearly every statement performs one action, and multiline expressions are formatted clearly. Reading flow: The authentication lifecycle is coherent and operations generally follow execution order, but protocol-specific terminology and scattered state mutations require careful tracking.
Run 2
Code Structure: Methods logically separate initialization, digest construction, response handling, and request integration, though digest construction handles many responsibilities. Nesting: Mostly shallow conditionals and early returns; nested hash helpers and retry handling add moderate complexity. Clarity of intent: Descriptive method names, type annotations, and comments explain the authentication workflow, but abbreviated variables, hexadecimal counters/status codes, stale comments, and implicit thread-local state obscure details. Code length: Reasonable for the functionality, but repeated hashing helpers, unused imports, and an inactive entdig branch add avoidable bulk. Action granularity: Statements generally perform one action per line; assignment expressions remain manageable, although the standalone r.content access has a non-obvious side effect. Reading flow: The request/challenge/retry sequence is coherent, with useful spacing, but long methods, protocol-specific terminology, and repeated state accesses increase cognitive load.
Run 3
Code Structure: Methods logically separate state initialization, digest generation, response handling, and request integration, although digest generation handles many responsibilities. Nesting: Mostly shallow conditionals and early returns keep complexity manageable; nested hash helpers add some depth. Clarity of intent: Descriptive method names, annotations, and comments explain the authentication workflow, but abbreviated variables, hexadecimal constants for ordinary counts/status codes, and an outdated lambda comment reduce clarity. Code length: Reasonable for the functionality, though repeated hashing helpers and verbose thread-local accesses add avoidable length. Action granularity: Nearly every line performs one action; the bare r.content access has an implicit side effect that is less obvious. Reading flow: The lifecycle and digest calculation proceed naturally, but protocol-specific terminology, long expressions, and interleaved state mutations require careful reading.