Sample
pyint-49bdec2e9b59-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.454 | 0–1; higher is more readable |
| Mi | 0.389 | 0–1; higher is more readable |
| LLOC | 79 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.296 | 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.181 | −6.271 |
Intercept 8.87 + feature contributions = -84.663 (log-odds).
Score = sigmoid(-84.663) = 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.825 | +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.064 | +0.323 |
| 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.952 | +0.321 |
Intercept 0.07 + feature contributions = -0.186 (log-odds).
Score = sigmoid(-0.186) = 0.454.
| Score | 0.389 |
|---|
| Score | 79 |
|---|
Run 1
This code is virtually unreadable due to the systematic replacement of descriptive method and variable names with meaningless single letters (a, b, c, d, f, g, h, etc.). While the structure mimics Django's ListView pattern, the obfuscation destroys clarity of intent, making every call site require reverse-engineering. Nesting is moderate, but the cryptic variables force the reader to constantly trace data flow without semantic cues. Code length is reasonable, but the single-letter naming makes it unnecessarily confusing rather than concise. Action granularity is acceptable, but the reading flow is severely disrupted. The only redeemable qualities are the inherited Django class structure and docstrings, which hint at the original purpose, but they cannot compensate for the deliberate opacity of the implementation.
Run 2
The code is structurally sound and follows Django conventions, but readability suffers severely from cryptic variable names and method names (a, b, c, d, f, g, h, i, j) that obscure intent. The nesting is moderate, but the use of single-letter variables like k, l, m, n, o, p, q, r makes the flow hard to follow without additional context. The docstrings help explain methods, but the names themselves provide no clues. The code is concise in some places, but the excessive abbreviation undermines clarity. Reading flow is disrupted by the need to mentally map abstract names to their purpose. While the structure is logical, the lack of descriptive naming prevents this from being considered highly readable.
Run 3
This code is extremely difficult to read due to deliberate obfuscation. Method names like 'a', 'b', 'c', 'd', 'f', 'g', 'h', 'i', 'j' completely obscure intent, forcing readers to infer purpose from docstrings alone. Variable names like 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 'B', 'C', 'D', 'E', 'F', 'G', 'H' provide zero semantic meaning. The pagination logic in method 'c' is deeply nested with multiple try-except blocks and conditional branches, making the flow difficult to follow. While each line generally performs one action, the cryptic naming destroys readability. The code structure is logically organized but the naming convention makes it practically unreadable. The docstrings are the only saving grace but do not compensate for the severe naming problems.
Run 1
Code Structure: Responsibilities are logically separated into queryset, pagination, configuration, and context methods. Nesting: Mostly shallow, with manageable conditionals and exception handling. Clarity of intent: Docstrings and descriptive class attributes help, but single-letter method, parameter, and variable names severely obscure meaning and require repeated cross-referencing. The error message references get_queryset(), although the corresponding method is named a(), adding confusion. Code length: Generally reasonable, though verbose getter docstrings and unnecessary line breaks add visual overhead. Action granularity: Most lines perform one clear operation, but tuple unpacking with opaque names makes several operations harder to interpret. Reading flow: Method grouping and consistent formatting support navigation, but cryptic calls such as self.d(B) and self.c(B, C) interrupt comprehension. Overall, the organization is sound, but naming substantially undermines readability.
Run 2
Code Structure: Logically organized into a mixin with focused methods for querying, ordering, pagination, and context construction. Nesting: Mostly shallow, with manageable conditionals and exception handling. Clarity of intent: Docstrings and descriptive configuration attributes help, but single-letter method names and variables severely obscure meaning and require constant cross-referencing. The error message references get_queryset(), which is named a() here, adding confusion. Code length: Reasonably concise, though trivial accessor methods and awkward multiline formatting add some overhead. Action granularity: Generally one action per line; tuple unpacking is appropriate, but cryptic names make its roles difficult to identify. Reading flow: Operations follow a sensible sequence, but calls such as self.d(B) and self.c(B, C), variable reuse, and inconsistent capitalization interrupt comprehension.
Run 3
Code Structure: Well-organized mixin with separate methods for querying, ordering, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional branches and exception handling. Clarity of intent: Docstrings and descriptive configuration attributes help, but single-letter method names and variables severely obscure roles and relationships; the error message references a method name absent from this class. Code length: Reasonably concise, though trivial accessor methods and unnecessary multiline formatting add overhead. Action granularity: Generally one operation per line, with conventional tuple unpacking and clear dictionary construction. Reading flow: Methods follow a logical progression, but opaque names force repeated cross-referencing, and reused variables such as q change meaning. Overall, sound organization and formatting provide moderate readability, substantially weakened by naming.