Sample
pyint-8c73e81b7703-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.36 | 0–1; higher is more readable |
| Mi | 0.618 | 0–1; higher is more readable |
| LLOC | 21 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.335 | 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. | 1208.391 | −39.877 |
| Source linesThe number of non-empty source lines. | 39 | +15.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.871 | −7.306 |
Intercept 8.87 + feature contributions = -22.713 (log-odds).
Score = sigmoid(-22.713) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 39 | +0.612 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 39 | −0.474 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 40 | −0.38 |
| 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. | 82.925 | +0.153 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 38.821 | +0.133 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.115 |
Intercept 0.07 + feature contributions = -0.576 (log-odds).
Score = sigmoid(-0.576) = 0.36.
| Score | 0.618 |
|---|
| Score | 21 |
|---|
Run 1
The code demonstrates a mix of clear and problematic elements. The import structure is logical and well-organized, showing good code structure. The class definition and method are relatively flat with minimal nesting. However, the inclusion of obfuscated dead code (the lI0O_77ccc4b7 variable manipulation) severely damages clarity of intent and reading flow. This code appears to be obfuscated or artificially complicated, making the purpose ambiguous. The action granularity is violated - multiple operations on single lines. While the core logic (preparing iexact query parameters) is concise, the unnecessary variable adds length without value. The reading flow is disrupted by the meaningless operations before the actual method logic. Without the obfuscated section, this would be quite readable; with it, the code becomes confusing. The Django-specific patterns (register_lookup, process_rhs) are standard but may require domain knowledge.
Run 2
The code is difficult to read due to several factors. The imports are unrelated to the class definition, suggesting poor organization. The critical issue is the presence of obfuscated/dead code (the lI0O_77ccc4b7 variable with bitwise operations and a conditional XOR) that serves no purpose and obscures intent. Nesting is shallow, which is positive, and the actual lookup logic (process_rhs) is relatively concise. However, the action granularity is inconsistent—mixing dead variable assignments with meaningful operations. The reading flow is severely disrupted by the meaningless obfuscated block before the actual method logic. While the variable and method names are descriptive, the overall clarity suffers from the inclusion of irrelevant code and unclear import context. The method itself would be readable if cleaned up, but as presented, the code requires significant mental filtering to understand.
Run 3
The code has clear imports and a reasonably structured class definition, but readability is severely undermined by the obfuscated variable names and meaningless bitwise operations in `process_rhs`. The variable `lI0O_77ccc4b7` appears to be dead code or a logic puzzle, adding confusion without purpose. Nesting is minimal and the action granularity is mostly one operation per line, but the reading flow breaks abruptly when encountering the cryptic block. The intent of the method—preparing right-hand side parameters for case-insensitive exact matching—is readable only if that obfuscated section is ignored. Code length is acceptable, and the structure is flat, but clarity of intent suffers dramatically in the middle of the snippet. Overall, it is partially readable but would be substantially improved by removing the meaningless variable and simplifying the logic.
Run 1
1. Code Structure: The lookup class and method are logically organized, but numerous unused imports and an unrelated arithmetic block add clutter. 2. Nesting: Shallow conditionals keep the code easy to navigate. 3. Clarity of intent: The class name, lookup name, and RHS preparation suggest case-insensitive exact matching, but the opaque variable name and ineffective bitwise operations obscure the method's purpose. 4. Code length: The meaningful implementation is concise; unnecessary imports and no-op statements substantially inflate the snippet. 5. Action granularity: Most lines perform one assignment or action, although the compound bitwise expression requires extra interpretation. 6. Reading flow: The superclass call, conditional parameter preparation, and return form a natural sequence, but the preceding obfuscation interrupts it. BuiltinLookup is also not defined or imported in the snippet, leaving some context unresolved.
Run 2
Code Structure: The lookup class and method are logically organized, but unrelated imports and an inserted no-op block add clutter. Nesting: Shallow conditionals keep the code easy to navigate. Clarity of intent: The class name, lookup_name, and Django method calls communicate case-insensitive lookup preparation; however, the cryptic variable and hexadecimal bitwise operations obscure intent without contributing useful behavior. Code length: The actual lookup logic is concise, but the redundant calculations and numerous unused imports unnecessarily lengthen this snippet. Action granularity: Each statement generally performs one action, although the compound bitwise expression increases cognitive load. Reading flow: The meaningful processing sequence is natural once reached, but the irrelevant block interrupts the method's flow and forces readers to determine whether it matters.
Run 3
Code Structure: The lookup class and method are logically organized, but numerous unrelated imports and a meaningless computation distract from the implementation. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: The class name, lookup_name, and RHS preparation communicate the intended behavior, while the opaque variable name and redundant bitwise operations obscure it. Code length: The actual lookup logic is concise, but unused imports and dead computation unnecessarily inflate the snippet. Action granularity: Statements generally perform one action per line, although the bitwise assignment combines several operations without explanatory value. Reading flow: The superclass call, conditional parameter preparation, and return form a natural sequence, but the unrelated arithmetic interrupts that flow.