Sample
pyint-63c43928c958-SRC
Unmodified source class
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.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.32 | 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.498 | −6.747 |
Intercept 8.87 + feature contributions = -227.296 (log-odds).
Score = sigmoid(-227.296) = 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.902 | +3.013 |
| 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.98 | −1.501 |
| 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.222 |
Intercept 0.07 + feature contributions = -2.473 (log-odds).
Score = sigmoid(-2.473) = 0.078.
| Score | 0.572 |
|---|
| Score | 160 |
|---|
Run 1
The code has decent organization with clear class structure and method separation, but suffers from several readability issues. The build_digest_header method is very long, deeply nested, and too procedural. Multiple similar functions (md5_utf8, sha_utf8, etc.) could be condensed — the code repeats itself with only the hash algorithm differing. The intent is somewhat clear for those familiar with HTTP Digest Auth, but the code is not beginner-friendly and uses many short variable names (KD, A1, HA2). Action granularity is mixed: some lines combine multiple operations, while others spread logically single actions over several lines. Reading flow is disrupted by the excessive 'XXX' comments, embedded type hints, and the overloaded __init__ signatures. The use of walrus operators adds brevity but reduces readability. While the code is not unreadable, a refactor with helper methods, reduced repetition, and clearer variable naming would improve maintainability.
Run 2
The code is structured into logical methods with clear responsibilities, but readability suffers from inconsistent type annotations, excessive inline comments marking incomplete features ('XXX'), and repetitive lambda definitions within `build_digest_header`. The nesting is moderate, though the long if-elif chain for algorithms could be simplified. Intent is mostly clear due to descriptive method names and comments, but ambiguous practices like redefining `HA1` based on algorithm and using `entdig` without implementation reduce clarity. Code length is reasonable but some segments (e.g., building `base` string) are verbose. Action granularity is adequate, with one operation per line in most places. Reading flow is mostly natural, but disjointed state handling via `_thread_local` and multiple `cast()` calls interrupt comprehension. Overall, functional but not polished for readability.
Run 3
The code has some clear strengths: it follows a logical class structure, has minimal nesting, and contains helpful comments. The use of type hints and documentation improves clarity. However, readability is reduced by several factors. The `build_digest_header` method is very long and complex, performing many distinct tasks (algorithm selection, string parsing, hash generation, internal state manipulation) that could be broken into smaller helper methods for better action granularity. The `handle_401` method also mixes several responsibilities (rewinding body, parsing headers, preparing request) and has a slightly tangled flow. While conditions are mostly flat, the repeated lambda definitions for hashing functions are verbose and could be simplified. The use of walrus operators (`:=`) and `cast()` calls may reduce clarity for some readers. Variable names like `s`, `A1`, and `KD` are somewhat cryptic. The comment "XXX not implemented yet" suggests incomplete parts that make the intent ambiguous. Overall, the code is maintainable but could benefit from refactoring the larger methods and improving naming for better comprehension.
Run 1
Code Structure: Methods logically separate initialization, digest generation, response handling, and request setup, but build_digest_header combines several responsibilities. Nesting: Mostly shallow, with moderate nesting in algorithm selection and retry handling. Clarity of intent: Descriptive method names, type hints, and comments explain the authentication workflow; terse variables such as s, KD, and _r, outdated comments, and implicit thread-local state reduce clarity. Code length: Repeated hash wrappers, verbose state access, and placeholder logic make the implementation longer than necessary. Action granularity: Generally one action per line, although assignment expressions combine lookup and condition checking, and r.content triggers a non-obvious side effect. Reading flow: The sequence from challenge parsing through digest construction to request retry is coherent, but the long digest-building method and cross-method state dependencies require careful tracking.
Run 2
Code Structure: Methods logically separate initialization, digest generation, response handling, and request preparation, although digest generation combines several responsibilities. Nesting: Mostly shallow conditionals and early returns keep control flow manageable; nested hash helpers add some complexity. Clarity of intent: Descriptive method names, annotations, and explanatory comments communicate the authentication workflow, but cryptic variables such as s, KD, and respdig, implicit thread-local state, and outdated comments reduce clarity. Code length: Repeated hashing helpers and the lengthy digest-building method could be simplified; unused imports and placeholder logic add noise. Action granularity: Almost every line performs a single action, making state changes and request preparation easy to follow. Reading flow: The sequence generally follows the authentication lifecycle naturally, but understanding protocol-specific calculations and tracing shared state across hooks require extra effort.
Run 3
Code Structure: Methods logically separate initialization, digest generation, response handling, and request setup, though digest generation combines several responsibilities. Nesting: Mostly shallow, with early returns reducing complexity; nested hash helpers and retry handling add moderate depth. Clarity of intent: Descriptive method names, type annotations, and protocol comments help, but terse variables such as s, KD, and _r, implicit thread-local state, and an outdated lambda comment reduce clarity. Code length: Reasonable for the protocol complexity, but repeated hashing helpers and lengthy header construction could be simplified. Action granularity: Generally one action per line; assignment expressions remain manageable, although the standalone r.content access has a non-obvious side effect. Reading flow: Follows a natural authentication sequence with useful spacing, but long methods, scattered state mutations, and unused imports interrupt the flow.