Sample
pyint-998ae8a04559-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.459 | 0–1; higher is more readable |
| Mi | 0.357 | 0–1; higher is more readable |
| LLOC | 79 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.405 | 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. | 4408.188 | −145.47 |
| Source linesThe number of non-empty source lines. | 146 | +58.4 |
| 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.323 | −6.485 |
Intercept 8.87 + feature contributions = -84.685 (log-odds).
Score = sigmoid(-84.685) = 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. | 147 | −4.168 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 132 | +3.829 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 133 | −2.631 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 145.762 | +1.628 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 82.912 | +0.533 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.423 |
| 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.932 | +0.153 |
Intercept 0.07 + feature contributions = -0.164 (log-odds).
Score = sigmoid(-0.164) = 0.459.
| Score | 0.357 |
|---|
| Score | 79 |
|---|
Run 1
This code is extremely difficult to read due to misleading naming, convoluted logic, and poor separation of concerns. Method names like fetchAccount, validateMessage, validateSession, validateScore, validateBalance, validateAddress, and validateRequest bear no relation to their actual functionality (e.g., fetchAccount retrieves a queryset, validateMessage handles pagination). Variables like nextUser, nextData, nextEvent, recentScore, activeUser, data, channel, and destination are generic and confusing, obscuring intent. The code is deeply nested with multiple conditional branches and try/except blocks stacked together. Multiple actions are packed into single lines (e.g., tuple unpacking with multiple assignments). The reading flow is disorganized—logical operations are scattered across methods with names suggesting validation but performing unrelated tasks. Although the code length is not excessive, the pervasive ambiguity and misleading identifiers make it nearly unreadable. It resembles obfuscated code, not production-quality Django internals.
Run 2
This code is severely obfuscated. Method names like fetchAccount, fetchMessage, validateMessage, validateSession, validateScore, validateBalance, validateAddress, validateRequest, and validateAccount bear no relation to their actual functions (get_queryset, get_ordering, paginate_queryset, get_paginate_by, get_paginator, get_paginate_orphans, get_allow_empty, get_context_object_name, get_context_data). Variable names such as nextUser, nextData, finalUser, recentScore, activeUser, discount, currentMode, nextPath, nextIndex, primaryMessage, nextToken, node, activeConfig, channel are nonsensical, making the logic impossible to follow. The code structure is tangled, with confusing indirection through meaningless helper methods. Reading flow is completely unnatural, requiring constant mental mapping between obfuscated and intended names. Even the docstrings are misleadingly named, further damaging clarity of intent. This appears to be the standard Django MultipleObjectMixin intentionally renamed to destroy readability; there is no logical organization or clarity.
Run 3
This code is highly unreadable due to deliberately misleading naming that obscures its actual Django pagination functionality. Method names like fetchAccount, fetchMessage, validateMessage, validateSession, validateScore, validateBalance, validateAddress, and validateRequest bear no relation to their real purposes (get_queryset, get_ordering, paginate_queryset, get_paginate_by, get_paginator, get_paginate_orphans, get_allow_empty, get_context_object_name). Variable names like nextUser, nextData, finalUser, category, activeUser, recentScore, and node are equally confusing. The logic itself is standard Django ListView mixin code, but the obfuscated naming destroys clarity of intent. While code structure is technically logical and nesting is moderate, the reading flow is fundamentally broken because readers must constantly map misleading names to actual functionality. Action granularity is acceptable, but the code is unnecessarily difficult to follow due to semantic misdirection rather than structural complexity. This appears intentionally obfuscated or the result of automated variable renaming without semantic understanding.
Run 1
Code Structure: Logically separated methods organize queryset retrieval, pagination, and context construction, although misleading names obscure those boundaries. Nesting: Mostly shallow, with manageable conditionals and exception handling. Clarity of intent: The main weakness; names such as fetchAccount, validateMessage, nextUser, and primaryBalance do not describe their actual roles. Docstrings help, but the error message references get_queryset rather than fetchAccount, adding confusion. Code length: Reasonably concise for its responsibilities, with some repetitive context dictionary construction. Action granularity: Most lines perform one action; tuple unpacking and the chained page-selection expression remain manageable. Reading flow: Formatting and method grouping are consistent, but readers must repeatedly translate arbitrary identifiers into meaningful concepts and follow indirect helper calls. Overall, the clean layout and useful documentation are substantially undermined by naming.
Run 2
Code Structure: Logically organized into a mixin with focused methods for querying, pagination, and context creation. Nesting: Mostly shallow, with manageable conditional branches and exception handling. Clarity of intent: Docstrings and familiar Django attributes explain the overall purpose, but misleading method names such as fetchAccount and validateMessage, plus arbitrary variable names, obscure actual responsibilities. Code length: Reasonably concise, though numerous trivial accessor methods add navigation overhead. Action granularity: Generally one action per line, with readable multiline calls; tuple unpacking and returning several pagination values require extra interpretation. Reading flow: Formatting and method grouping are consistent, but tracing calls is difficult because names do not reflect their operations. The error message references get_queryset despite the method being named fetchAccount, further weakening coherence. Overall, sound structural readability is substantially undermined by confusing naming.
Run 3
Code Structure: Logically divided into small methods for queryset retrieval, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional branches and exception handling. Clarity of intent: Severely weakened by misleading method and variable names such as fetchAccount, validateMessage, and nextUser; docstrings clarify purpose but conflict with naming. Code length: Generally concise, although numerous trivial accessor methods increase navigation overhead. Action granularity: Most lines perform one action; tuple unpacking and chained fallback expressions remain manageable. Reading flow: Formatting and method grouping are consistent, but arbitrary names force repeated cross-referencing. The error message references get_queryset(), which is not defined here, and paginator keyword names conflict with the wrapper's renamed parameters, further undermining confidence in the intended behavior.