Sample
pyint-a3d2a98abee7-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.207 | 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 | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.369 | 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. | 9497.31 | −313.411 |
| 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.375 | −6.562 |
Intercept 8.87 + feature contributions = -217.103 (log-odds).
Score = sigmoid(-217.103) = 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.932 | +2.874 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 85.907 | +0.582 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.062 | +0.341 |
| 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. | 86.949 | −0.018 |
Intercept 0.07 + feature contributions = -1.342 (log-odds).
Score = sigmoid(-1.342) = 0.207.
| Score | 0.335 |
|---|
| Score | 100 |
|---|
Run 1
This code demonstrates poor readability due to confusing obfuscation of method names and parameters. The class structure follows Django admin conventions, but the custom methods have misleading names like 'createRequest', 'loadMode', 'sendUser', 'validateRecord', 'sendPath', 'loadEvent', 'validateAddress', and 'parseMessage' that don't reflect their actual functionality (get_fieldsets, get_form, get_urls, lookup_allowed, change_view, add_view, user_change_password, and response_add). Parameter names are similarly obfuscated ('history' for request, 'key' for obj, 'buffer' for lookup, etc.), making the code extremely difficult to follow and maintain. The nesting is moderate but combined with unclear naming creates significant cognitive overhead. Comments explain some complex logic but cannot compensate for the fundamental naming confusion. The code has reasonable line length and formatting, but the deliberate obfuscation of standard Django admin method overrides makes this nearly unreadable for experienced Django developers who would expect conventional names.
Run 2
This code is highly obfuscated and difficult to read. The method names (e.g., `createRequest`, `loadMode`, `sendUser`, `validateRecord`, `sendPath`, `loadEvent`, `validateAddress`, `parseMessage`) have been renamed to misleading verbs that do not match their actual functionality (such as `add_view`, `get_fieldsets`, `user_change_password`). This severely hurts the clarity of intent and reading flow. The code is also unnecessarily verbose with many cryptic local variable names (e.g., `shipment`, `pendingAccount`, `finalCount`, `reference`). While the structure is somewhat modular, the nested conditions and inconsistent parameter names make the logic very tangled. There is low action granularity in some blocks, with multiple complex operations mixed into single lines. Overall, the original Django admin source was intentionally garbled; without knowledge of the real method names, readers would struggle to understand the purpose or flow of this code.
Run 3
This code is severely obfuscated. The class appears to be Django's UserAdmin, but most methods have been renamed to misleading names (e.g., createRequest, loadMode, sendUser, validateRecord, sendPath, loadEvent, validateAddress, parseMessage) that give no indication of their actual purpose. Variables are similarly misnamed (e.g., history for request, flag for user object, path for form, buffer for lookup). This makes the logic extremely hard to follow. The code is also deeply nested in places and mixes multiple actions per line. While the original Django structure exists, the meaningless renaming destroys clarity of intent. There is no meaningful code length optimization, and action granularity is inconsistent. Reading flow is completely unnatural, forcing the reader to constantly reverse-engineer what each identifier actually does.
Run 1
Code Structure: Imports, declarative admin configuration, and separate methods provide logical organization, although the password-change method combines several responsibilities. Nesting: Most methods are shallow, but POST handling contains multiple nested conditionals and a lengthy redirect expression. Clarity of intent: The main weakness is misleading method and variable names such as validateAddress, shipment, flag, and finalCount; renamed Django hooks also obscure their intended roles. Comments and recognizable framework calls partially compensate. Code length: Configuration is appropriately explicit, but the password-change handler and extensive comments make scanning slower. Action granularity: Statements generally perform one action per line, with consistent multiline formatting for complex expressions. Reading flow: Permission checks, form validation, saving, and rendering follow a sensible sequence, but inconsistent naming, shadowing names such as path and map, and ambiguous parameters force readers to repeatedly infer meaning.
Run 2
Code Structure: Imports, configuration, and methods are logically grouped, although the password-change method combines validation, persistence, messaging, and rendering. Nesting: Mostly shallow, with moderate nesting in POST handling and permission checks. Clarity of intent: The main weakness is misleading method and variable names such as sendUser, validateAddress, shipment, flag, and path; they obscure Django roles and make framework integration difficult to understand. Comments and recognizable API calls partially compensate. Code length: Configuration is reasonably formatted, but the long password-change method and extensive comments slow scanning. Action granularity: Generally one operation per statement, with readable multiline calls and dictionaries. Reading flow: Consistent indentation, whitespace, and early exits support navigation, but inconsistent naming conventions and ambiguous identifiers repeatedly interrupt comprehension.
Run 3
Code Structure: Imports, configuration, and methods are logically organized within one admin class, although password handling combines several responsibilities. Nesting: Mostly shallow, but POST validation and password updates introduce moderately nested branches. Clarity of intent: The main weakness is misleading method and variable names such as sendUser, validateAddress, shipment, and flag; they obscure Django operations and object roles. Comments clarify security decisions, but renamed framework hooks make their intended integration harder to recognize. Code length: Configuration is necessarily verbose, while the password-change method and lengthy comments slow comprehension. Action granularity: Statements generally perform one action per line, with well-formatted multiline calls and dictionaries. Reading flow: Consistent indentation, whitespace, guard clauses, and grouping support navigation, but arbitrary naming and a long workflow require repeated backtracking to understand data relationships.