Sample
pyint-57a2b5b62153-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.874 | 0–1; higher is more readable |
| Mi | 0.266 | 0–1; higher is more readable |
| LLOC | 36 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 8.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.441 | 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. | 1929.052 | −63.659 |
| Source linesThe number of non-empty source lines. | 84 | +33.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.74 | −7.109 |
Intercept 8.87 + feature contributions = -28.298 (log-odds).
Score = sigmoid(-28.298) = 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. | 85 | −1.973 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 61 | +1.373 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 83.862 | +0.762 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.547 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77.165 | +0.441 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 78.976 | +0.32 |
Intercept 0.07 + feature contributions = 1.938 (log-odds).
Score = sigmoid(1.938) = 0.874.
| Score | 0.266 |
|---|
| Score | 36 |
|---|
Run 1
The code is severely obfuscated through meaningless variable renames that destroy all clarity of intent. Parameters like 'key' (actually a Flask app), 'size' (actually a path), 'nextItem' (actually base_url), 'timestamp' (actually subdomain), 'finalBatch' (actually url_scheme), and 'step'/'target' (actually *args/**kwargs) actively mislead the reader. The instantiation of an EnvironBuilder with 'age' (actually parsed URL) and 'schedule' (actually APPLICATION_ROOT) makes the logic nearly impossible to follow. The assertion condition is convoluted and hard to parse. While the code structure is somewhat preserved and nesting is minimal, the semantic scrambling defeats readability. The docstrings retain original meaning but contradict the renamed parameters, creating further confusion. This appears to be intentionally obfuscated code that a maintainer would struggle to understand or modify safely.
Run 2
The code is moderately readable but suffers from poor naming that obscures intent. The constructor logic is flat, and the class structure is logical, but parameters like 'key', 'size', 'nextItem', 'timestamp', 'finalBatch', 'step', and 'target' are misleading and do not reflect their actual roles (e.g., 'key' is actually a Flask app, 'timestamp' represents a subdomain). This creates ambiguity and hurts clarity of intent and reading flow. The assertion message refers to 'subdomain' and 'url_scheme', which are not visible in the signature, further confusing the reader. The method 'fetchEvent' is reasonably concise and structured, though its parameter name 'map' is also ambiguous. Overall, the code is organized and not deeply nested, but poor naming and a mismatch between documentation and actual parameter names reduce readability.
Run 3
The code is difficult to read due to misleading naming: parameters like 'key', 'size', 'nextItem', 'timestamp', 'finalBatch', 'step', 'target', 'map' don't reflect their actual roles (app, path, base_url, subdomain, url_scheme, args, kwargs, obj). The docstring uses correct terms, creating confusion. The __init__ logic is tangled: the assert condition is complex and involves non-obvious XOR logic using boolean equality. Variable names like 'cachedKey', 'schedule', 'age' further obscure intent. URL construction spans multiple f-strings with unclear ordering. The method 'fetchEvent' has a misleading name and docstring (says 'Serialize obj' but parameter is 'map'). Imports are mostly unused. While the code is not deeply nested and mostly one action per line, the poor naming, confusing boolean logic, and disorganized flow make it hard to understand quickly.
Run 1
Code Structure: Imports, a class, and separate methods provide logical organization, though several imports appear unused. Nesting: Mostly shallow, with only a few nested conditionals. Clarity of intent: The main weakness is misleading names such as key, size, timestamp, finalBatch, and fetchEvent; these obscure application, URL, subdomain, scheme, and JSON serialization roles. Docstrings describe different parameter names than the signatures, adding confusion. Code length: The implementation is reasonably concise, but extensive documentation loses value because it does not match the code. Action granularity: Most lines perform one action, although the compound assertion and URL construction require careful parsing. Reading flow: Environment setup follows a sensible sequence, but inconsistent naming, the dense assertion, and documentation mismatches repeatedly interrupt comprehension.
Run 2
Code Structure: Imports, class definition, constructor, and serialization method are logically organized, although many imports are unused in this snippet. Nesting: Mostly shallow, with straightforward conditional branches. Clarity of intent: Severely weakened by misleading names such as key, size, nextItem, timestamp, and finalBatch; these do not match the documented app, path, base_url, subdomain, and url_scheme concepts. fetchEvent also obscures its JSON-serialization purpose, and map shadows a built-in. Code length: The implementation is reasonably concise, but lengthy documentation describes different parameter names. Action granularity: Most lines perform one action; the compound assertion is harder to parse. Reading flow: URL construction follows a sensible sequence, but inconsistent naming, documentation mismatches, and the unexplained Flask annotation interrupt comprehension.
Run 3
Code Structure: Imports and a focused class provide logical organization, with initialization and serialization separated. Nesting: Mostly shallow, with manageable conditional blocks. Clarity of intent: The main weakness is misleading names such as key, size, nextItem, timestamp, and finalBatch, which obscure application, path, URL, subdomain, and scheme roles. Docstrings describe different parameter names, and fetchEvent does not communicate JSON serialization. The compound assertion is difficult to parse, and Flask has no visible import. Code length: Implementation is reasonably concise, though documentation is lengthy relative to the functionality. Action granularity: Statements generally perform one action per line; URL construction is sensibly split across lines. Reading flow: Configuration lookup, URL parsing, and superclass initialization follow a natural sequence, but inconsistent naming and documentation force readers to repeatedly infer meaning.