Sample
pyint-6faf2c417d3e-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.007 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 192 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.231 | 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. | 13194.193 | −435.408 |
| Source linesThe number of non-empty source lines. | 422 | +168.8 |
| 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.459 | −6.689 |
Intercept 8.87 + feature contributions = -264.427 (log-odds).
Score = sigmoid(-264.427) = 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. | 423 | −13.941 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 333 | +10.781 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 333 | −7.22 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 421.969 | +5.488 |
| 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. | 129.967 | −1.84 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 129.988 | +1.293 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.416 |
Intercept 0.07 + feature contributions = -4.953 (log-odds).
Score = sigmoid(-4.953) = 0.007.
| Score | 0.561 |
|---|
| Score | 192 |
|---|
Run 1
The code is virtually unreadable due to systematically obfuscated identifiers (e.g., methods a, b, c, d; parameters m, n, o, q; local variables B, D, E, F). This destroys clarity of intent and reading flow. The logic structure is preserved but hidden behind meaningless names. Nesting is moderate but irrelevant when names convey nothing. Action granularity is acceptable but negated by the inability to discern what actions mean. The original requests library code is readable, but this version deliberately replaces descriptive names (prepare, prepare_url, prepare_headers, url, params, etc.) with single letters, making all comments and docstrings disconnected from the actual code. Even imports are unaffected; the class definition and docstrings remain, but they cannot compensate for the loss of semantic naming. Overall, this is a textbook example of poor readability due to naming obfuscation, not structural complexity.
Run 2
This code is severely obfuscated. Method names (a through l) and parameter names (m through x, then A through ai) are systematically replaced with meaningless single or double letters, destroying any clarity of intent. While the original structure (imports, class layout, method organization) is logical, the deliberate renaming makes the code unreadable. Docstrings remain but don't match the cryptic implementations. Nesting and length are reasonable, but action granularity and reading flow are completely broken by the loss of semantic naming. This is essentially a manual obfuscation of what was originally readable code.
Run 3
The code is severely obfuscated through meaningless single-letter variable names (a through aj) and method names (a through l), making the code extremely difficult to read and maintain. The original library code is well-structured, but this modification deliberately obscures all semantic meaning. While the underlying organization and control flow remain logical, the naming destroys clarity of intent, reading flow, and action granularity comprehension. The code has moderate nesting and reasonable length, but these are overwhelmed by the impossible-to-follow naming scheme.
Run 1
Code Structure: Request preparation is logically divided into focused methods, with a central orchestration method. Nesting: Mostly moderate, but body preparation contains several nested branches and exception handlers. Clarity of intent: Docstrings, comments, and type annotations help, but single-letter method names and opaque variables severely obscure meaning and force readers to repeatedly infer roles. Comments referencing original method names also create disconnects. Code length: Generally justified by HTTP edge cases, though lengthy imports, verbose annotations, and some redundant comments add overhead. Action granularity: Most lines perform one action, making individual operations straightforward to follow. Reading flow: The preparation sequence is coherent, but cryptic calls, dense type-ignore comments, and long conditional lines interrupt comprehension. Overall, sound organization and documentation partially compensate for pervasive naming obfuscation.
Run 2
Code Structure: Request preparation is logically separated into methods, with a clear orchestration sequence. Nesting: Mostly manageable, but body preparation has several nested branches that increase cognitive load. Clarity of intent: Docstrings, comments, and type annotations help substantially, but opaque method names (a–l) and variable names (B, T, aa) obscure responsibilities and data meanings. Comments also reference descriptive method names absent from this version. Code length: Generally justified by HTTP edge cases, though extensive imports, verbose comments, and typing workarounds add clutter. Action granularity: Most lines perform one action, making individual operations easy to isolate. Reading flow: Preparation stages follow a sensible order, but understanding calls and tracking URL components or body state requires repeatedly consulting definitions and comments. Overall, sound organization is significantly undermined by non-descriptive naming.
Run 3
Code Structure: Request preparation is logically divided into focused methods, although the large import block adds clutter. Nesting: Mostly moderate, but body preparation contains several nested branches that increase cognitive load. Clarity of intent: Docstrings, comments, and type annotations explain responsibilities, but single-letter method and variable names severely obscure operations and data roles; comments referring to original method names compound this problem. Code length: Reasonable for the functionality, though extensive comments, typing workarounds, and some redundant branching add verbosity. Action granularity: Most lines perform one action, making individual statements easy to isolate. Reading flow: Preparation follows a sensible sequence, and validation uses helpful early exits, but understanding calls such as self.f(n, t) requires repeatedly consulting definitions. Overall, sound organization is substantially undermined by opaque naming.