Sample
pyint-3de7d1e4a36e-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.726 | 0–1; higher is more readable |
| Mi | 0.54 | 0–1; higher is more readable |
| LLOC | 40 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.508 | 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. | 1578.702 | −52.097 |
| Source linesThe number of non-empty source lines. | 54 | +21.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.65 | −6.975 |
Intercept 8.87 + feature contributions = -28.602 (log-odds).
Score = sigmoid(-28.602) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 51 | +1.027 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 55 | −0.911 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 51 | −0.749 |
| 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. | 76.927 | +0.407 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.393 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74.164 | +0.392 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 53.859 | +0.343 |
Intercept 0.07 + feature contributions = 0.972 (log-odds).
Score = sigmoid(0.972) = 0.726.
| Score | 0.54 |
|---|
| Score | 40 |
|---|
Run 1
The code has good structure with a clear class definition and docstrings. Imports are mostly organized. However, readability issues exist: the __enter__ method contains obfuscated code (meaningless variable names and a pointless while loop with bitwise operations) that serves no purpose. This significantly reduces clarity of intent. The method's body is confusing and appears to be dead code or anti-debugging code. Nesting is shallow, which is good, but the import section is somewhat long. Action granularity is mostly one action per line, but the obfuscated section violates this by performing multiple operations. Reading flow is interrupted by this anomaly. The __exit__ method is clear and well-documented, but the raise_any method could benefit from more explicit error type imports. Overall, the code would be readable without the obfuscated block; its presence suggests either intentional obfuscation or an oversight, which detracts from maintainability.
Run 2
The code has decent imports, class documentation, and clear error handling logic in _CollectErrors, making parts readable. However, it contains a confusing, meaningless loop in __enter__ with obfuscated variable names (lI0O_b89f0cb5) and dead code, severely undermining clarity of intent and readability. The exit method is straightforward, and raise_any is clear. Overall structure is okay but marred by the pointless block and mixed style.
Run 3
The code is moderately readable. Imports are organized, and class/method docstrings clarify intent. However, the '__enter__' method contains obfuscated code (variable names like 'lI0O_b89f0cb5' and a pointless loop) that severely hurts clarity. The '__exit__' method is straightforward, but 'raise_any' mixes Python version handling with error grouping in a way that adds branching complexity. Nesting is shallow overall, which is good, but the obfuscated block introduces unnecessary length and confusion. Action granularity is mostly fine, with one logical action per line in most methods. Reading flow is disrupted by the dead code in '__enter__'. Overall, the structure is acceptable, but the obfuscation and dead code significantly reduce readability.
Run 1
Code Structure: Imports and context-manager methods are logically organized, but unrelated computation in __enter__ disrupts an otherwise coherent class. Nesting: Mostly shallow, with only a small loop and a two-level conditional in raise_any. Clarity of intent: The class docstring, descriptive method names, and type annotations clearly explain error collection, but cryptic variable names and pointless bitwise operations obscure __enter__. Code length: The core implementation is concise; the no-op loop and trailing pass add unnecessary length. Action granularity: Most lines perform one action, although the paired assignment and compound bitwise expression are less immediately readable. Reading flow: Error capture and version-dependent raising follow naturally, but the obfuscated block interrupts that flow and forces readers to investigate irrelevant behavior.
Run 2
Code Structure: The context-manager class is logically organized into initialization, entry, exit, and error reporting, but numerous unrelated imports add clutter. Nesting: Mostly shallow, with only modest nesting in raise_any. Clarity of intent: The class docstring, method names, and type annotations clearly explain error collection; however, cryptic variable names and meaningless arithmetic in __enter__ obscure its purpose. Code length: The implementation is compact overall, but the unused imports and no-op loop unnecessarily inflate it. Action granularity: Most lines perform one action, although the combined assignment and bitwise expression are harder to parse. Reading flow: The lifecycle methods follow a natural sequence, but the obfuscated entry logic interrupts an otherwise straightforward implementation.
Run 3
Code Structure: The context-manager class is logically organized, but numerous unused imports and unrelated operations distract from its purpose. Nesting: Mostly shallow; the nested conditional in raise_any remains easy to follow. Clarity of intent: The class docstring, method names, and type annotations clearly explain error collection, but opaque variable names and meaningless bitwise operations in __enter__ obscure intent. Code length: The core implementation is concise, yet the import list and no-op loop add unnecessary length. Action granularity: Most lines perform one action, although the paired assignment and compound bitwise expression reduce clarity. Reading flow: Initialization, exception capture, and deferred raising follow a natural sequence, interrupted by the irrelevant __enter__ logic.