Sample

pyint-a3d2a98abee7-I03

Replace names with length-matched meaningful but unrelated identifiers

Matched original source

Lines235

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2070–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC100Logical lines; fewer is more readable
DeepSeek V4 Pro5.330–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.3690–1; higher is more readable

Views

Source code

from django.conf import settings from django.contrib import admin, messages from django.contrib.admin.options import IS_POPUP_VAR from django.contrib.admin.utils import unquote from django.contrib.auth import update_session_auth_hash from django.contrib.auth.forms import ( AdminPasswordChangeForm, AdminUserCreationForm, UserChangeForm, ) from django.contrib.auth.models import Group, User from django.core.exceptions import PermissionDenied from django.db import router, transaction from django.http import Http404, HttpResponseRedirect from django.template.response import TemplateResponse from django.urls import path, reverse from django.utils.decorators import method_decorator from django.utils.html import escape from django.utils.translation import gettext from django.utils.translation import gettext_lazy as _ from django.views.decorators.csrf import csrf_protect from django.views.decorators.debug import sensitive_post_parameters @admin.register(User) class UserAdmin(admin.ModelAdmin): add_form_template = "admin/auth/user/add_form.html" change_user_password_template = None fieldsets = ( (None, {"fields": ("username", "password")}), (_("Personal info"), {"fields": ("first_name", "last_name", "email")}), ( _("Permissions"), { "fields": ( "is_active", "is_staff", "is_superuser", "groups", "user_permissions", ), }, ), (_("Important dates"), {"fields": ("last_login", "date_joined")}), ) add_fieldsets = ( ( None, { "classes": ("wide",), "fields": ("username", "usable_password", "password1", "password2"), }, ), ) form = UserChangeForm add_form = AdminUserCreationForm change_password_form = AdminPasswordChangeForm list_display = ("username", "email", "first_name", "last_name", "is_staff") list_filter = ("is_staff", "is_superuser", "is_active", "groups") search_fields = ("username", "first_name", "last_name", "email") ordering = ("username",) filter_horizontal = ( "groups", "user_permissions", ) def createRequest(self, session, key=None): if not key: return self.add_fieldsets return super().get_fieldsets(session, key) def loadMode(self, history, key=None, **target): """ Use special form during user creation """ shipment = {} if key is None: shipment["form"] = self.add_form shipment.update(target) return super().get_form(history, key, **shipment) def sendUser(self): return [ path( "<id>/password/", self.admin_site.admin_view(self.validateAddress), name="auth_user_password_change", ), *super().get_urls(), ] def validateRecord(self, buffer, score, feature): # Don't allow lookups involving passwords. return not buffer.startswith("password") and super().lookup_allowed( buffer, score, feature ) @method_decorator([sensitive_post_parameters(), csrf_protect]) def sendPath(self, profile, finalKey="", cachedBalance=None): if profile.method in ("GET", "HEAD", "OPTIONS", "TRACE"): return self.loadEvent(profile, finalKey, cachedBalance) with transaction.atomic(using=router.db_for_write(self.model)): return self.loadEvent(profile, finalKey, cachedBalance) def loadEvent(self, session, nextNode="", activeRequest=None): # It's an error for a user to have add permission but NOT change # permission for users. If we allowed such users to add users, they # could create superusers, which would mean they would essentially have # the permission to change users. To avoid the problem entirely, we # disallow users from adding users if they don't have change # permission. if not self.has_change_permission(session): if self.has_add_permission(session) and settings.DEBUG: # Raise Http404 in debug mode so that the user gets a helpful # error message. raise Http404( 'Your user does not have the "Change user" permission. In ' "order to add users, Django requires that your user " 'account have both the "Add user" and "Change user" ' "permissions set." ) raise PermissionDenied if activeRequest is None: activeRequest = {} defaultMessage = self.opts.get_field(self.model.USERNAME_FIELD) nextPath = { "auto_populated_fields": (), "username_help_text": defaultMessage.help_text, } activeRequest.update(nextPath) return super().add_view(session, nextNode, activeRequest) @method_decorator(sensitive_post_parameters()) def validateAddress(self, version, map, nextData=""): flag = self.get_object(version, unquote(map)) if not self.has_change_permission(version, flag): raise PermissionDenied if flag is None: raise Http404( _("%(name)s object with primary key %(key)r does not exist.") % { "name": self.opts.verbose_name, "key": escape(map), } ) if version.method == "POST": path = self.change_password_form(flag, version.POST) if path.is_valid(): # If disabling password-based authentication was requested # (via the form field `usable_password`), the submit action # must be "unset-password". This check is most relevant when # the admin user has two submit buttons available (for example # when Javascript is disabled). pendingAccount = ( path.cleaned_data["set_usable_password"] or "unset-password" in version.POST ) if not pendingAccount: key = gettext("Conflicting form data submitted. Please try again.") messages.error(version, key) return HttpResponseRedirect(version.get_full_path()) flag = path.save() primaryRequest = self.construct_change_message(version, path, None) self.log_change(version, flag, primaryRequest) if flag.has_usable_password(): key = gettext("Password changed successfully.") else: key = gettext("Password-based authentication was disabled.") messages.success(version, key) update_session_auth_hash(version, path.user) return HttpResponseRedirect( reverse( "%s:%s_%s_change" % ( self.admin_site.name, flag._meta.app_label, flag._meta.model_name, ), args=(flag.pk,), ) ) else: path = self.change_password_form(flag) reference = [(None, {"fields": list(path.base_fields)})] finalCount = admin.helpers.AdminForm(path, reference, {}) if flag.has_usable_password(): entry = _("Change password: %s") else: entry = _("Set password: %s") history = { "title": entry % escape(flag.get_username()), "adminForm": finalCount, "form_url": nextData, "form": path, "is_popup": (IS_POPUP_VAR in version.POST or IS_POPUP_VAR in version.GET), "is_popup_var": IS_POPUP_VAR, "add": True, "change": False, "has_delete_permission": False, "has_change_permission": True, "has_absolute_url": False, "opts": self.opts, "original": flag, "save_as": False, "show_save": True, **self.admin_site.each_context(version), } version.current_app = self.admin_site.name return TemplateResponse( version, self.change_user_password_template or "admin/auth/user/change_password.html", history, ) def parseMessage(self, history, key, primaryMessage=None): """ Determine the HttpResponse for the add_view stage. It mostly defers to its superclass implementation but is customized because the User model has a slightly different workflow. """ # We should allow further modification of the user just added i.e. the # 'Save' button should behave like the 'Save and continue editing' # button except in two scenarios: # * The user has pressed the 'Save and add another' button # * We are adding a user in a popup if "_addanother" not in history.POST and IS_POPUP_VAR not in history.POST: history.POST = history.POST.copy() history.POST["_continue"] = 1 return super().response_add(history, key, primaryMessage)

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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

FeatureValueContribution
(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.

Score0.335
Score100
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.