Sample
pyint-f229e6146ebc-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.011 | 0–1; higher is more readable |
| Mi | 0.598 | 0–1; higher is more readable |
| LLOC | 173 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.241 | 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. | 10608.2 | −350.071 |
| Source linesThe number of non-empty source lines. | 271 | +108.4 |
| 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.439 | −6.658 |
Intercept 8.87 + feature contributions = -239.459 (log-odds).
Score = sigmoid(-239.459) = 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. | 245 | +7.737 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 245 | −5.201 |
| 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. | 189.963 | −4.381 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 270.869 | +3.376 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 190 | +2.261 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.216 |
Intercept 0.07 + feature contributions = -4.48 (log-odds).
Score = sigmoid(-4.48) = 0.011.
| Score | 0.598 |
|---|
| Score | 173 |
|---|
Run 1
The code has major readability problems. The most severe issue is the pervasive use of inverted conditional logic like `if not (condition): pass else: ...`, which inverts natural reading flow and should simply be `if condition: ...`. This pattern makes even simple checks confusing and verbose. Additionally, the code reverses standard Python idioms (e.g., `if not (not hasattr(...))`), obscuring intent. Several functions are excessively long (`build_digest_header`, `handle_401`) with many branches and repeated hash-function definitions. Comments like `# XXX not implemented yet` and unused variables (`entdig`) add ambiguity. While there is a clear structure with typed attributes and method separation, the overall clarity is severely undermined by the unnatural conditional style and inflated length.
Run 2
The code has clear structure (class, methods) and some explicit type-hints, but readability is severely harmed by the many `if not (...): pass else:` anti-patterns. This inverts natural logic flow and creates redundant nesting/noise. Loops of assignments inside conditional blocks (e.g., building the digest header) use the same awkward pattern, making intent hard to follow. Several repeated hash function definitions add verbosity. Action granularity is poor—some lines do multiple operations (e.g., `self._thread_local.nonce_count = 1` after inverted condition) and comments are sparse. The use of `overload` and class-level annotations is good, but they don't compensate for the awkward control flow and verbose `return None` fallbacks. The code would be far more readable with straightforward `if`/`else` or guard clauses.
Run 3
This code is highly unreadable despite some positive attributes. The main issue is the bizarre inverted conditional pattern: `if not (condition): pass else: ...` appears throughout, creating deeply confusing logic that reads backwards and obscures intent. This pattern appears 12+ times, forcing readers to mentally invert every condition. Action granularity is poor - multiple operations are often crammed into single comprehensions or expressions, while trivial assignments are spread across multiple lines. The `init_per_thread_state()` method is particularly egregious with its double negative. The overly verbose type hints and overloads add noise without clarifying behavior. Long methods like `build_digest_header()` mix concerns: algorithm selection, string construction, digest computation, and header formatting. While some sections demonstrate good naming conventions and logical grouping, the pervasive inverted conditionals destroy reading flow and make even simple operations mentally taxing. The code works against Python's natural readability rather than with it.
Run 1
Code Structure: Responsibilities are separated into initialization, digest construction, response handling, and request hooks, but digest construction is oversized and repetitive. Nesting: Depth is moderate, yet numerous inverted conditions with empty pass branches add unnecessary control-flow complexity. Clarity of intent: Method names, annotations, and protocol comments help, but double negations, terse cryptographic variables, and a stale lambda comment obscure intent. Code length: Repeated hashing helpers and verbose conditional patterns substantially inflate the implementation; duplicated inline comments add clutter. Action granularity: Most lines perform one action, although assignment expressions combine lookup and testing, and the bare r.content access hides a side effect. Reading flow: The authentication sequence is broadly logical, but repeated not-condition/pass/else patterns force readers to mentally reverse conditions and interrupt an otherwise coherent progression.
Run 2
Code Structure: Responsibilities are separated into initialization, digest construction, response handling, and request hooks, but digest construction is oversized and repetitive. Nesting: Mostly moderate, although nested hash helpers and unnecessary if/pass/else blocks add complexity. Clarity of intent: Method names, annotations, and protocol comments help, but repeated negations, double negatives, abbreviated variables, and duplicated inline comments obscure straightforward logic. Code length: Repeated hashing helpers and empty branches make the implementation unnecessarily long; unused imports add noise. Action granularity: Generally strong, with one operation per line and clearly separated state updates. Reading flow: The authentication lifecycle is logically ordered, but inverted conditions and no-op branches repeatedly interrupt natural reading. Overall, the code is understandable with effort, yet avoidable verbosity and awkward conditional expressions substantially reduce readability.
Run 3
Code Structure: Methods logically separate initialization, digest construction, response handling, and request preparation, but digest construction is oversized and repetitive. Nesting: Generally moderate, though nested helper functions and unnecessary if/pass/else branches add complexity. Clarity of intent: Method names, annotations, and protocol comments help, but pervasive negated conditions, occasional double negatives, abbreviated variables, and duplicated comments obscure straightforward logic. Code length: Repeated hashing helpers, redundant branches, unused imports, and placeholder logic make the code unnecessarily long. Action granularity: Most lines perform one action, making individual operations easy to follow; the assignment expressions are reasonably contained. Reading flow: The authentication sequence is coherent, but inverted conditions and empty branches repeatedly interrupt natural reading and force readers to mentally reconstruct simpler positive checks.