Sample
pyint-21bd6c464ca4-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.069 | 0–1; higher is more readable |
| Mi | 0.616 | 0–1; higher is more readable |
| LLOC | 135 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.254 | 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. | 9143.007 | −301.719 |
| Source linesThe number of non-empty source lines. | 314 | +125.6 |
| 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.379 | −6.569 |
Intercept 8.87 + feature contributions = -173.818 (log-odds).
Score = sigmoid(-173.818) = 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. | 315 | −10.117 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 246 | +7.772 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 246 | −5.224 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 313.924 | +3.978 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.956 | +0.663 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.447 |
| 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. | 90.965 | −0.188 |
Intercept 0.07 + feature contributions = -2.599 (log-odds).
Score = sigmoid(-2.599) = 0.069.
| Score | 0.616 |
|---|
| Score | 135 |
|---|
Run 1
The code is heavily obfuscated and nearly unreadable despite containing useful inline comments. Meaningful identifiers have been replaced with single-letter or sequential variable names (e.g., `a`, `b`, `c`, `B`, `C`, `D`, `E`), destroying clarity of intent. Nesting is deep inside `d`, which mixes multiple actions (redirect parsing, cookie handling, proxy/auth rebuild, yielding) in a single long method. Reading flow is disorganized because readers cannot infer what variables represent without deciphering comments and logic. Code structure exists only in method boundaries; internals are tangled. The use of comments suggests the logic was originally clear, but the renaming negates that. Action granularity is also poor, with many operations per loop iteration. Overall, only the method docstrings and comments keep this from being completely unreadable.
Run 2
The code is severely obfuscated: single-letter variable names (a–aa), method names without semantic meaning, and scattered logic across multiple methods. While comments remain descriptive, they don't compensate for the loss of intent in identifiers. Nesting is moderate but the redirect loop mixes many concerns (history, cookies, proxies, auth, method rewriting) in one place. Reading flow is poor due to non-mnemonic names and long generator method. Structure is technically separated into helpers, but they are impossible to understand without mapping variables. Action granularity is acceptable, but overall clarity is very low.
Run 3
This code is severely obfuscated. All variable and method names are replaced with meaningless single letters (a, b, C, E, G, J, etc.), making it nearly impossible to understand the logic without prior knowledge of the original code. While the structure is somewhat organized and comments remain, the loss of semantic naming destroys clarity of intent and reading flow. The code has moderate nesting and acceptable action granularity, but the cryptic identifiers add enormous cognitive load. Even with the insightful comments, readers must constantly map letters to concepts like 'redirect location' or 'prepared request'. The import statements and docstrings survive, but they cannot compensate for the unreadable local variables and method signatures.
Run 1
Code Structure: Related redirect behaviors are organized into separate methods, but the main redirect generator combines many responsibilities. Nesting: Mostly shallow conditionals and early returns; the generator adds moderate nesting through a loop, exception handling, and branches. Clarity of intent: Descriptive class names, API calls, docstrings, and comments explain the domain, but opaque method names and alphabetic variables severely obscure meaning and relationships. Code length: Most helpers are reasonably concise, while the redirect generator is long and requires tracking substantial mutable state. Action granularity: Statements generally perform one action per line, with clear formatting and readable multiline calls. Reading flow: Operations follow a logical redirect-processing sequence, but repeated interpretation of meaningless identifiers and cross-references between ambiguously named methods disrupts comprehension. Overall, solid formatting and documentation partially compensate for highly uninformative naming.
Run 2
Code Structure: Redirect handling is logically divided into helper methods, but the main redirect generator combines many responsibilities. Nesting: Mostly shallow conditionals and early returns, with moderate nesting inside the redirect loop. Clarity of intent: Single-letter method and variable names severely obscure purpose and relationships; descriptive comments, docstrings, and type annotations partially compensate. Code length: Generally justified by protocol complexity, although the long redirect method and extensive commentary increase reading effort. Action granularity: Most lines perform one action, making individual operations easy to isolate. Reading flow: Operations follow a sensible redirect-processing sequence, but opaque names and calls such as self.e and self.f force readers to repeatedly consult definitions.
Run 3
1. Code Structure: Logically divided into redirect, authentication, proxy, and method-handling helpers, but the central redirect generator combines many responsibilities. 2. Nesting: Generally moderate, with early returns and mostly shallow conditionals; the redirect loop adds some complexity. 3. Clarity of intent: Single-letter method and variable names severely obscure meaning and relationships. Docstrings, comments, and descriptive library calls partially compensate. 4. Code length: Mostly justified by protocol edge cases, although the long redirect method, extensive comments, and unused imports increase reading effort. 5. Action granularity: Usually one action per line, with clear separation between operations and no compressed statement chains. 6. Reading flow: Processing steps follow a sensible sequence, supported by explanatory comments, but opaque helper calls and repeated variable reassignment require frequent backtracking.