Sample
pyint-76e701e8aab4-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.12 | 0–1; higher is more readable |
| Mi | 0.442 | 0–1; higher is more readable |
| LLOC | 160 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9 | 0–20; mean of three runs |
| BTTF | 0.229 | 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. | 10073.379 | −332.421 |
| 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.468 | −6.703 |
Intercept 8.87 + feature contributions = -232.254 (log-odds).
Score = sigmoid(-232.254) = 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.922 | +3.014 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 100.98 | +0.825 |
| 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. | 100.984 | −0.612 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.082 | +0.147 |
Intercept 0.07 + feature contributions = -1.997 (log-odds).
Score = sigmoid(-1.997) = 0.12.
| Score | 0.442 |
|---|
| Score | 160 |
|---|
Run 1
The code is extremely difficult to read due to deliberately obfuscated naming. Variables like 'a', 'b', 'c', 'e', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 't', 'u', 'v', 'w', 'y', 'z', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P' have no semantic meaning, making intent completely unclear. Method names are equally opaque. While the structure is technically linear and nesting is moderate, the single-letter variables create artificial complexity. The logic copies standard HTTPDigestAuth but obscures every identifier, making even simple operations like 'hash_utf8' appear as undeclared references. The code length is reasonable for the functionality but unintelligible. Action granularity and reading flow are destroyed by the need to constantly mentally map meaningless symbols to concepts. This reads like deliberately deobfuscated code.
Run 2
The code's core logic is recognizable as HTTP Digest Auth, but readability is severely degraded by single-letter variable names (j, k, l, m, n, o, p, etc.), single-letter method names (a, b, c, e), and generic function names (KD, A, B, C). This obscures intent and forces readers to mentally map symbols to concepts like 'username' or 'nonce'. The structure is reasonably flat and actions are mostly separated per line, but the overly terse naming and excessive use of intermediate variables (like `I` for the qop string) increase cognitive load. The code relies on comments to explain logic that should be self-evident from good naming. While the flow follows authentication steps, the abbreviation of parameters and methods makes it feel disorganized. Overall, the code is functional but unreadable for maintainers.
Run 3
The code is very difficult to read due to single-letter variable names throughout (a, b, c, e, j, k, l, m, n, o, p, q, t, u, v, etc.), which obscures intent and breaks reading flow. Method names are also meaningless (a, b, c, e). While structure is somewhat organized, the heavy use of cryptic abbreviations, inline walrus operators, and compact f-strings reduces clarity. Nesting is moderate but combined with poor naming makes comprehension difficult. Action granularity is acceptable but readability suffers significantly.
Run 1
Code Structure: Class methods separate initialization, digest construction, response handling, and request setup, but digest construction combines many responsibilities. Nesting: Generally moderate, with early returns limiting depth; nested hash helpers and conditionals add complexity. Clarity of intent: The class name, comments, and type hints provide context, but single-letter method names and sequential variable names severely obscure meaning. KD references undefined hash_utf8 rather than the selected hash function, further confusing the logic. Code length: Repeated encoding/hash helpers and verbose state management make the implementation longer than necessary. Action granularity: Most lines perform one action, although assignment expressions and standalone S.content introduce less obvious operations. Reading flow: Authentication steps follow a mostly logical sequence, but tracing anonymous variables across the long digest method and between cryptically named methods requires substantial effort.
Run 2
Code Structure: Responsibilities are separated into methods, but the large digest-building method mixes algorithm selection, state updates, hashing, and header formatting. Nesting: Mostly moderate, with early returns limiting depth; nested hash functions add complexity. Clarity of intent: The class name, comments, and some attributes explain authentication behavior, but single-letter method and variable names severely obscure meaning. KD references undefined hash_utf8 rather than the selected hashing function, further confusing interpretation. Code length: Repeated hashing wrappers and verbose thread-local accesses make the implementation longer than necessary. Action granularity: Generally one action per line, with readable statement separation; assignment expressions introduce minor compression. Reading flow: Authentication follows a broadly logical sequence, but readers must repeatedly decode opaque identifiers and track mutable state across methods. Stale comments, unused imports, and unresolved names also interrupt comprehension.
Run 3
Code Structure: Authentication responsibilities are separated into methods, but the digest-building method mixes algorithm selection, nonce management, hashing, and header formatting. Nesting: Generally moderate, with early returns limiting depth; nested hashing functions add some complexity. Clarity of intent: The class name, comments, and some state fields are informative, but single-letter method names and pervasive arbitrary variable names obscure most operations. KD references undefined hash_utf8 rather than the selected hashing function, further confusing intent. Code length: Repeated hashing wrappers and verbose thread-local accesses make the implementation longer than necessary. Action granularity: Most lines perform one action, although assignment expressions combine lookup and branching. Reading flow: The overall initialization, challenge handling, and request-retry sequence is logical, but cryptic identifiers force repeated backtracking, and stale comments and minimal docstrings provide insufficient guidance.