Sample
pyint-6c833f0c6010-I12
Inline all eligible single-use intermediate local variables
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 | 14.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 is generally readable with clear class structure, type hints, and docstrings. It follows a logical flow: state initialization, header building, and response handling. Nesting depth is mostly manageable, though handle_401 has some branching. The build_digest_header method is long but well-segmented, with inline comments explaining non-obvious parts. Action granularity is good—most lines perform one operation. However, some sections reduce clarity: repeated lambdas for hash algorithms could be consolidated; the 'XXX not implemented yet' entdig variable is dead code; and a few lines (e.g., string concatenations with time.ctime() and os.urandom) could be broken down. Overall, the code is above average but could be slightly more concise and consistent.
Run 2
The code shows moderate readability. Structure is logical with clear class and method separation, but methods are large with heavy branching. Nesting is mostly flat, but `build_digest_header` has deep if/elif chains and nested functions. Intent is reasonably clear via docstrings and comments, though many `XXX` comments signal unresolved logic. Length is verbose—duplicated lambda-like hash functions could be consolidated. Action granularity is mixed: some lines bundle operations (e.g., `s += nonce...`), while others are clean. Reading flow is interrupted by type casts, overloads, and inline `if` assignments. Overall, understandable but not concise or elegant.
Run 3
The code is generally readable with clear intent and logical organization. The class structure is coherent, and methods are reasonably separated by responsibility. Type hints and docstrings improve clarity. However, several factors reduce readability: the `build_digest_header` method is long with many conditional branches and nested function definitions, increasing cognitive load. Variable names like `KD`, `HA1`, `HA2`, and `respdig` are cryptic and assume domain knowledge. Multiple `XXX` comments highlight unfinished or unclear logic. Some lines combine multiple operations (e.g., `s = str(...).encode(...)` then subsequent appends), though most actions are per-line. Nesting is moderate but could be flatter. The use of `threading.local` and dynamic attribute assignment is slightly opaque. Overall, the code is maintainable but would benefit from refactoring the digest-building method into smaller helpers and using more descriptive variable names.
Run 1
1. Code Structure: Methods separate initialization, header construction, response handling, and request setup logically, but build_digest_header combines several responsibilities. 2. Nesting: Generally moderate, with early returns limiting depth; nested hash helpers and conditional request handling add complexity. 3. Clarity of intent: Type hints, method names, and explanatory comments help, but abbreviated variables such as s, KD, and _r require interpretation. Some comments are outdated, and thread-local state makes dependencies less explicit. 4. Code length: Mostly justified by protocol requirements, though repeated hash helpers, unused imports, and placeholder logic add avoidable length. 5. Action granularity: Almost every statement performs one action; the standalone r.content expression is less intuitive despite its comment. 6. Reading flow: Authentication steps follow a sensible sequence, but the long digest-building method and repeated thread-local accesses interrupt an otherwise natural flow.
Run 2
Code Structure: Methods logically separate state initialization, digest construction, response handling, and request hooks, but digest construction combines several responsibilities. Nesting: Mostly shallow, with early returns limiting complexity; nested hash helpers and conditional request handling add moderate depth. Clarity of intent: Descriptive method names, annotations, and protocol comments help, but abbreviated variables such as s, KD, and respdig, stale comments, and implicit thread-local state reduce clarity. Code length: Repeated hashing helpers and a long digest-building method could be consolidated; some imports appear unused. Action granularity: Generally one operation per line, with no dense statement packing, although assignment expressions and the standalone r.content access require extra interpretation. Reading flow: Authentication steps follow a coherent sequence, but repeated algorithm branches, extensive thread-local access, and protocol-specific terminology interrupt an otherwise natural flow.
Run 3
Code Structure: Methods logically separate initialization, digest construction, response handling, and request preparation, although digest construction 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, type hints, and useful comments explain the authentication workflow, but cryptic variables such as s, KD, and _r, placeholder comments, and implicit thread-local state reduce clarity. Code length: Repeated hashing helpers and the long digest-building method could be simplified; some imports appear unused. Action granularity: Statements generally perform one action per line, with no dense compound statements; the standalone r.content access has a non-obvious side effect. Reading flow: The sequence from challenge parsing through hashing, header construction, and retrying is coherent, but protocol-specific terminology, repeated thread-local accesses, and occasional stale comments interrupt readability.