Sample
pyint-be949521de88-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.198 | 0–1; higher is more readable |
| Mi | 0.335 | 0–1; higher is more readable |
| LLOC | 100 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.33 | 0–20; mean of three runs |
| BTTF | 0.379 | 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. | 9538.49 | −314.77 |
| Source linesThe number of non-empty source lines. | 235 | +94 |
| 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.371 | −6.556 |
Intercept 8.87 + feature contributions = -218.456 (log-odds).
Score = sigmoid(-218.456) = 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. | 236 | −7.32 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 210 | +6.527 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 210 | −4.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 234.91 | +2.874 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.894 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.065 | +0.313 |
| 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. | 87.992 | −0.062 |
Intercept 0.07 + feature contributions = -1.398 (log-odds).
Score = sigmoid(-1.398) = 0.198.
| Score | 0.335 |
|---|
| Score | 100 |
|---|
Run 1
The code suffers from extremely poor naming (e.g., `get`, `get2`, `get3`, `lookup2`, `add`, `add2`, `user2`, parameters like `req3`, `obj2`, `def2`), which obscures intent and breaks readability. Many methods are misleading or incorrectly overridden. Structure is tangled: some methods contain large monolithic blocks with multiple actions and mixed responsibilities (e.g., `user2`). Nesting is moderately deep in places, and reading flow is unnatural because method names do not reflect purpose. Although the class layout starts conventionally with attributes and fieldsets, the subsequently malformed method overrides destroy clarity. There is some concise grouping of admin options, but overall the code requires significant effort to understand. It rates poorly because clear intent, structural organization, and action granularity are severely compromised despite partial Django conventions.
Run 2
This code is severely unreadable due to pervasive non-descriptive naming (get2, get3, user2, add2, req4, obj3, def3, for2), which obscures intent and forces constant mental mapping. It is unnecessarily verbose and convoluted, with methods that do too much and contain deeply nested conditionals (especially user2). The structure mimics Django's UserAdmin but adds layers of confusion through renamed/overridden methods without clear purpose. Action granularity is poor: many lines bundle multiple operations or obscure logic. Reading flow is disorganized, mixing custom logic with Django internals in a way that is hard to follow. While there are some comments, they do not compensate for the cryptic identifiers and tangled control flow. The code appears to be an obfuscated version of standard Django admin user management, making it harder to maintain and debug.
Run 3
The code is very difficult to read due to poor naming conventions. Functions and variables use non-descriptive names like `get`, `get2`, `get3`, `lookup2`, `obj2`, `req3`, `def2`, `def3`, `for2`, `use`, `tit`, `con`, etc. Many method overrides (e.g., `get`, `response`) seem broken or misdirected (calling `self.add_fieldsets` from `get`). The `get2` method shadows intended behavior with confusing parameters and only conditionally sets the form. Deeply nested logic, especially in `user2` and `add2`, makes the flow hard to follow. Critical actions and conditional branches are packed into long blocks. There is little separation of concerns or logical grouping, and the overall purpose of each method is often ambiguous despite docstrings. The code relies heavily on unexplained abbreviations and parameter re-declaration, making it hard to maintain or debug.
Run 1
1. Code Structure: Imports, configuration attributes, and separate methods provide logical organization, although the password-change method combines validation, persistence, messaging, and rendering. 2. Nesting: Most methods are relatively flat, but the POST/form-validation/password-handling branches introduce moderate nesting. 3. Clarity of intent: Django APIs, configuration names, and explanatory comments clarify behavior, but generic names such as get2, user2, req6, for2, and con substantially obscure intent; renamed framework hooks also make their intended roles harder to recognize. 4. Code length: Most configuration and formatting are justified, though lengthy comments and the large password-change method slow scanning. 5. Action granularity: Statements generally perform one action per line, with readable multiline expressions and no compressed statement chains. 6. Reading flow: Consistent indentation, spacing, and early exits support natural flow, but numbered identifiers require repeated context tracking and the long workflow interrupts easy comprehension.
Run 2
Code Structure: Configuration and behavior are logically separated into methods, but generic method names obscure their roles and relationships to Django hooks. Nesting: Most methods are shallow, though the password-change handler has several nested branches and a nested redirect expression. Clarity of intent: Django APIs, comments, and configuration convey the overall purpose, but names such as get2, req6, for2, and con substantially hinder understanding. Code length: Much of the length is justified by configuration and security checks, although the password handler combines several responsibilities and comments are occasionally verbose. Action granularity: Statements generally perform one action per line, with clear formatting of collections and calls. Reading flow: Configuration-first organization and early permission checks support a natural flow, but readers must repeatedly infer variable meanings and mentally translate renamed methods into their intended framework roles.
Run 3
Code Structure: Configuration and behavior are separated into methods, but generic method names obscure their roles and intended Django overrides. Nesting: Most methods remain shallow, though the password-change handler combines several nested branches. Clarity of intent: Comments, framework calls, and configuration names explain the overall purpose, but identifiers such as get2, req6, for2, and con significantly hinder understanding. Code length: Much of the length reflects necessary configuration, but the large password-change method and lengthy comments increase reading effort. Action granularity: Statements generally perform one action per line, with readable formatting for compound expressions and dictionaries. Reading flow: Imports, configuration, and handlers follow a coherent sequence, and early returns help navigation; however, inconsistent naming forces readers to repeatedly infer what variables and methods represent.