Sample
pyint-38c87b367c7a-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.294 | 0–1; higher is more readable |
| Mi | 0.427 | 0–1; higher is more readable |
| LLOC | 78 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.348 | 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. | 5516.529 | −182.045 |
| Source linesThe number of non-empty source lines. | 170 | +68 |
| 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.48 | −6.72 |
Intercept 8.87 + feature contributions = -111.896 (log-odds).
Score = sigmoid(-111.896) = 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. | 171 | −5.018 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 136 | −2.7 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 169.818 | +1.964 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 85.953 | +0.582 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.069 | +0.276 |
| 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. | 86.982 | −0.019 |
Intercept 0.07 + feature contributions = -0.878 (log-odds).
Score = sigmoid(-0.878) = 0.294.
| Score | 0.427 |
|---|
| Score | 78 |
|---|
Run 1
The code structure is logical, but readability is severely degraded by poor naming conventions. Attributes and methods use single-letter or meaningless names like `a`, `b`, `c`, `d`, `e`, `f`, `g`, `h`, `i`, `j`, `k`, `l`, `m`, `n`, `o`, `p`, `q`, `r`, `s`, `u`, `v`, `w`, `x`, `y`, `z`, `A`, `B`, `C`. This makes intent ambiguous despite docstrings. Nesting is moderate but complex request-building logic in method `d` involves multiple nested branches, reducing flow. Action granularity is mostly one action per line, but dense lines with multiple operations hurt clarity. The original names likely were descriptive, and the obfuscation significantly lowers readability.
Run 2
The code has a clear structure with meaningful class and method organization, but variable names are severely degraded (single letters like 'a', 'b', 'c', 'i', 'j', 'k', 'l', 'x', 'y'), making the intent hard to understand without reading the documentation carefully. Nesting is moderate; method 'd' has some if-else branching but is not deeply nested. Multiple actions are sometimes combined on one line, reducing readability. The use of abbreviations for parameters ('e', 'f', 'g', 'h', 'm', 'o', 'p') further obscures the purpose. While docstrings clarify behavior, the variable naming is a major drawback. The flow is logical, but the poor names force extra cognitive effort. It is not unreadable due to proper organization and comments, but the variable naming significantly lowers the score.
Run 3
The code is largely unreadable due to single-letter variable names that obscure meaning, function names like 'a', 'b', 'c', 'd' that give no indication of purpose, and fragmented logic that disrupts reading flow. Type annotations are present but do not compensate for poor naming. The structure contains excessive blank lines and comments that fail to clarify intent. Nesting is moderate but the ambiguous identifiers make the flow hard to follow. The code length is moderate, but action granularity suffers from condensed operations and unclear separation of concerns. Overall, the code requires significant effort to understand and maintain.
Run 1
Code Structure: Responsibilities are separated into methods, with logical session, request, and context management. Nesting: Mostly shallow, although request-type dispatch introduces moderate nesting. Clarity of intent: Severely weakened by single-letter method, parameter, and variable names; docstrings and comments help, but references to session_transaction and args do not match the actual names. Code length: Reasonably concise for the functionality, though lengthy documentation contrasts with opaque implementations. Action granularity: Generally one action per line, making individual operations easy to follow. Reading flow: Execution proceeds naturally within methods, but cryptic identifiers and unresolved references such as EnvironBuilder and _get_werkzeug_version force readers to infer meaning or consult external context.
Run 2
Code Structure: Responsibilities are separated into methods, with coherent request, session, and context management. Nesting: Mostly shallow, although request-type dispatch adds moderate branching. Clarity of intent: The largest weakness is single-letter method and variable names, which obscure roles and require tracing operations. Docstrings and comments help, but references to session_transaction and args do not match the renamed identifiers. Code length: Reasonably concise for the functionality, though lengthy documentation contrasts with cryptic implementation names. Action granularity: Generally one action per line, with clear assignments and calls. Reading flow: Sequential operations, early exits, and try/finally support natural reading, but opaque identifiers and externally defined types interrupt comprehension.
Run 3
Code Structure: Methods separate session handling, environment preparation, request construction, and context management logically. Nesting: Mostly shallow, with manageable conditional branching in request handling. Clarity of intent: Severely weakened by single-letter method and variable names; descriptive attributes, type hints, and documentation partially compensate. Some comments and examples reference names absent from the code, creating confusion. Code length: Generally proportionate to the functionality, although the lengthy session docstring contrasts with its opaque method name. Action granularity: Most lines perform one action, with a few compact expressions combining environment construction or request preparation. Reading flow: Execution proceeds naturally within methods, but deciphering identifiers and tracing calls between a, b, c, and d repeatedly interrupts comprehension. Overall, sound organization and formatting are undermined by pervasive ambiguous naming.