Sample
pyint-b9f7ce10cac6-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.464 | 0–1; higher is more readable |
| Mi | 0.371 | 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 | 11 | 0–20; mean of three runs |
| BTTF | 0.526 | 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. | 4413.988 | −145.662 |
| 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.271 | −6.406 |
Intercept 8.87 + feature contributions = -84.798 (log-odds).
Score = sigmoid(-84.798) = 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.863 | +1.629 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77.313 | +0.443 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.059 | +0.365 |
| 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.946 | +0.321 |
Intercept 0.07 + feature contributions = -0.142 (log-odds).
Score = sigmoid(-0.142) = 0.464.
| Score | 0.371 |
|---|
| Score | 79 |
|---|
Run 1
This code is extremely difficult to read due to severely obfuscated naming conventions. Methods are named sequentially (get2 through get9) with no semantic meaning, forcing readers to trace logic to understand purpose. Variable names like 'que', 'que2', 'pag2', 'con', and 'kwa2' obscure intent and make the code nearly impossible to follow. The paginate method has multiple responsibilities (parameter parsing, error handling, pagination logic) violating single action granularity. Reading flow is disrupted by arbitrary ordering of methods and unclear control flow. While the structure appears somewhat organized with separate methods, the naming defeats any benefit. Nesting is moderate but excessive try/except blocks add confusion. The code is concise in lines but verbose in cognitive load—each abbreviated name requires mental mapping. Only the docstrings provide some clarity, but they contradict the method names which provide no hints. This appears to be deliberately obfuscated code masquerading as Django's MultipleObjectMixin.
Run 2
This code is extremely unreadable. The method names (get2 through get9) are meaningless and obscure their purposes (get_queryset, get_ordering, get_paginate_by, get_paginator, get_paginate_orphans, get_allow_empty, get_context_object_name, get_context_data). Variable names are also poor: que, que2, que3, pag, pag2, pag3, con, ord, orp, kwa. The paginate method does too much: it retrieves the page number, handles the 'last' page case, validates it, paginates, and returns a tuple, violating single responsibility. The get9 method has complex branching and mixes concerns. While the original Django code this is based on is well-structured, this obfuscated version strips away all semantic meaning. The code structure exists but is completely destroyed by terrible naming and over-complex methods, making intent impossible to discern without deep analysis.
Run 3
The code is highly unreadable due to meaningless method names like get2, get3, get4, get5, get6, get7, get8, and get9, which obscure their purposes. Variables like que, que2, pag2, pag3, pag4, kwa, and con further reduce clarity. The mixin does too much: querying, ordering, pagination, and context building are all crammed into a single class with poor separation. Several methods have confusing signatures (e.g., get5 with **kwa) and inconsistent naming. Some sections like paginate are awkwardly structured. While Django's style is generally clean, this code abandons descriptive naming and clear flow, making maintenance difficult.
Run 1
Code Structure: Responsibilities are logically separated into queryset, ordering, pagination, and context methods, but numbered method names obscure their relationships. Nesting: Generally shallow, with manageable conditional branches and exception handling. Clarity of intent: Docstrings and Django conventions help, but names such as get2, que5, pag4, and is2 make execution difficult to follow. Reusing pag2 for both a page identifier and a page object adds ambiguity. Renamed parameters also conflict with supplied keyword arguments, undermining confidence in the intended behavior. Code length: Mostly reasonable, though repeated context dictionaries and awkward line wrapping add unnecessary bulk. Action granularity: Most lines perform a single action; tuple unpacking is conventional and acceptable. Reading flow: Methods follow a broadly natural sequence, but readers must repeatedly consult docstrings and trace numbered variables. Overall, the structural organization is readable, while poor naming substantially reduces comprehension.
Run 2
Code Structure: Logically separated methods organize queryset retrieval, ordering, pagination, and context creation. Nesting: Generally shallow, with manageable conditional and exception blocks. Clarity of intent: Docstrings and Django conventions explain the overall purpose, but numbered methods such as get2–get9 and cryptic variables such as que5 and pag4 obscure individual responsibilities. Reusing pag2 for both a page identifier and a page object further complicates understanding. Code length: Mostly reasonable, though repeated context dictionaries and trivial accessor methods add verbosity. Action granularity: Statements generally perform one action per line, with appropriately formatted calls and dictionaries. Reading flow: Local control flow is natural, but tracing numbered helper calls requires frequent cross-referencing. The mismatch between get5's parameter names and the keyword arguments supplied by paginate also makes the interface confusing.
Run 3
Code Structure: Responsibilities are logically separated into queryset retrieval, ordering, pagination, and context construction. Nesting: Mostly shallow, with manageable conditionals and exception handling. Clarity of intent: Docstrings and Django conventions help, but numbered methods such as get2/get9 and abbreviated variables such as que5/pag4 obscure roles and require repeated cross-referencing. Reusing pag2 for both a page identifier and a page object further reduces clarity. Code length: Generally reasonable, although repetitive context dictionaries and awkward multiline formatting add unnecessary bulk. Action granularity: Most lines perform one clear operation; tuple unpacking is conventional and appropriate. Reading flow: Method organization is coherent, but opaque naming interrupts the flow. The error message references get_queryset rather than get2, and the paginator keyword names differ from the wrapper's explicit parameter names, making the interface harder to understand.