Sample
pyint-a7ee33597f81-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.076 | 0–1; higher is more readable |
| Mi | 0.572 | 0–1; higher is more readable |
| LLOC | 163 | 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.317 | 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. | 10080.211 | −332.647 |
| Source linesThe number of non-empty source lines. | 248 | +99.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.494 | −6.741 |
Intercept 8.87 + feature contributions = -231.318 (log-odds).
Score = sigmoid(-231.318) = 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. | 249 | −7.78 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 222 | +6.942 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 222 | −4.673 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 247.911 | +3.055 |
| 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.96 | −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.226 |
Intercept 0.07 + feature contributions = -2.497 (log-odds).
Score = sigmoid(-2.497) = 0.076.
| Score | 0.572 |
|---|
| Score | 163 |
|---|
Run 1
The code is structurally organized into a single class with clear method separation, but suffers from deep nesting in build_digest_header, especially the algorithm selection chain and nested inner functions. Intent is mostly clear, but several sections (e.g., handle_redirect's pointless loop, cryptic variable names like KD, cnonce, qop) obscure purpose. Some actions are combined per line reasonably, but block comments are sparse and some blocks are hard to follow. The file is fairly long, but that is partly justified by digest auth complexity. However, the overuse of inner function definitions inside conditional branches hurts readability, and the unreachable/dead code (entdig, fake toggle loop) adds confusion. Overall, competent but not highly readable.
Run 2
The code shows moderate readability. Structure is logical with clear class organization and method separation. However, there are several readability issues: the build_digest_header method is too long with nested conditionals and multiple similar lambda definitions that could be refactored. There's dead/confusing code (e.g., the feature_enabled loop in handle_redirect that does nothing, and the unused entdig variable). Type hints and walrus operators are mixed in ways that sometimes obscure rather than clarify. The action granularity is generally good with one action per line, and reading flow is reasonable despite some areas where intent is unclear (e.g., nonce_count reset logic). Deep nesting appears in the algorithm selection and qop handling. Overall, functional but could benefit from extraction of digest algorithm handling into separate methods/constants and removal of dead code.
Run 3
The code is reasonably structured with clear sections and type hints, but several readability issues prevent a higher score. The build_digest_header method is overly long (40+ lines) and contains multiple responsibilities: algorithm selection, hash function definition, digest computation, and header assembly. This reduces clarity of intent. Nesting is mostly flat, which is good, but some blocks like the handle_redirect method contain dead code (feature_enabled loop) that adds confusion. Action granularity is generally one action per line, but some lines are dense, e.g., combining assignment with conditional expressions. Reading flow is interrupted by inline comments that explain 'what' rather than 'why' and by the large nested elif chain in build_digest_header. The code would benefit from extracting smaller helper methods (e.g., _get_hash_function, _build_digest_response, _format_header). Magic strings and repeated f-string concatenation in header building also reduce clarity. However, per-thread state management and 401 handling are logically organized, and naming conventions are mostly clear.
Run 1
Code Structure: Methods logically separate initialization, digest generation, response handling, and request setup, although digest generation handles too many responsibilities. Nesting: Mostly shallow, with early returns limiting complexity; nested hash helpers and authentication branches add some depth. Clarity of intent: Descriptive method names, type annotations, and protocol comments help, but abbreviated variables, stale comments, implicit thread-local state, and the unused feature-toggle loop obscure intent. Code length: Repeated hashing wrappers, unused imports, and redundant code make the implementation longer than necessary. Action granularity: Generally one action per line, with readable multiline expressions; the standalone r.content access has a non-obvious side effect. Reading flow: The authentication lifecycle is reasonably natural, but lengthy digest construction, repeated thread-local accesses, and scattered state updates require careful tracking.
Run 2
Code Structure: Responsibilities are separated into initialization, digest construction, response handling, and comparison methods, although digest construction handles many concerns. Nesting: Mostly shallow, with early returns limiting complexity; nested hash helpers and authentication branches add moderate depth. Clarity of intent: Method names, annotations, and protocol comments help, but abbreviated variables, stale comments, unexplained attribute access for side effects, and the pointless feature_enabled loop obscure intent. Code length: Repeated hash wrappers and verbose thread-local access make the implementation longer than necessary. Action granularity: Most lines perform one action, with only occasional combined assignment and condition checks. Reading flow: Authentication proceeds in a generally logical sequence, but the long digest method, inline helper definitions, irrelevant redirect loop, and unused imports interrupt the flow.
Run 3
Code Structure: Methods logically separate initialization, digest construction, response handling, and request preparation, 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: Method names, annotations, and comments explain authentication behavior, but terse protocol variables, stale comments, unused imports, and the pointless feature-toggle loop obscure intent. Code length: Repeated hashing helpers and the long digest-building method could be simplified; some annotations and comments add noise. Action granularity: Nearly every line performs one action, although the standalone r.content access has an implicit side effect that requires its comment. Reading flow: Authentication progresses naturally from challenge parsing to digest calculation and retry, but frequent thread-local accesses, inline casts, and unfinished-feature markers interrupt the flow.