Sample

pyint-93dc4ffa5832-I04

Replace names with deterministic minifier-style shortest identifiers

Matched original source

Lines235

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2060–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 Sol10.330–20; mean of three runs
BTTF0.2210–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 a(self, i, j=None): if not j: return self.add_fieldsets return super().get_fieldsets(i, j) def b(self, k, l=None, **m): """ Use special form during user creation """ n = {} if l is None: n["form"] = self.add_form n.update(m) return super().get_form(k, l, **n) def c(self): return [ path( "<id>/password/", self.admin_site.admin_view(self.g), name="auth_user_password_change", ), *super().get_urls(), ] def d(self, o, p, q): # Don't allow lookups involving passwords. return not o.startswith("password") and super().lookup_allowed( o, p, q ) @method_decorator([sensitive_post_parameters(), csrf_protect]) def e(self, r, s="", t=None): if r.method in ("GET", "HEAD", "OPTIONS", "TRACE"): return self.f(r, s, t) with transaction.atomic(using=router.db_for_write(self.model)): return self.f(r, s, t) def f(self, u, v="", w=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(u): if self.has_add_permission(u) 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 w is None: w = {} x = self.opts.get_field(self.model.USERNAME_FIELD) y = { "auto_populated_fields": (), "username_help_text": x.help_text, } w.update(y) return super().add_view(u, v, w) @method_decorator(sensitive_post_parameters()) def g(self, z, A, B=""): C = self.get_object(z, unquote(A)) if not self.has_change_permission(z, C): raise PermissionDenied if C is None: raise Http404( _("%(name)s object with primary key %(key)r does not exist.") % { "name": self.opts.verbose_name, "key": escape(A), } ) if z.method == "POST": D = self.change_password_form(C, z.POST) if D.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). E = ( D.cleaned_data["set_usable_password"] or "unset-password" in z.POST ) if not E: F = gettext("Conflicting form data submitted. Please try again.") messages.error(z, F) return HttpResponseRedirect(z.get_full_path()) C = D.save() G = self.construct_change_message(z, D, None) self.log_change(z, C, G) if C.has_usable_password(): F = gettext("Password changed successfully.") else: F = gettext("Password-based authentication was disabled.") messages.success(z, F) update_session_auth_hash(z, D.user) return HttpResponseRedirect( reverse( "%s:%s_%s_change" % ( self.admin_site.name, C._meta.app_label, C._meta.model_name, ), args=(C.pk,), ) ) else: D = self.change_password_form(C) H = [(None, {"fields": list(D.base_fields)})] I = admin.helpers.AdminForm(D, H, {}) if C.has_usable_password(): J = _("Change password: %s") else: J = _("Set password: %s") K = { "title": J % escape(C.get_username()), "adminForm": I, "form_url": B, "form": D, "is_popup": (IS_POPUP_VAR in z.POST or IS_POPUP_VAR in z.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": C, "save_as": False, "show_save": True, **self.admin_site.each_context(z), } z.current_app = self.admin_site.name return TemplateResponse( z, self.change_user_password_template or "admin/auth/user/change_password.html", K, ) def h(self, L, M, N=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 L.POST and IS_POPUP_VAR not in L.POST: L.POST = L.POST.copy() L.POST["_continue"] = 1 return super().response_add(L, M, N)

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.9545.258−314.994
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.318−6.478

Intercept 8.87 + feature contributions = -218.601 (log-odds).
Score = sigmoid(-218.601) = 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.977+2.875
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.83.932+0.55
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.068+0.282
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.84.979+0.066

Intercept 0.07 + feature contributions = -1.348 (log-odds).
Score = sigmoid(-1.348) = 0.206.

Score0.335
Score100
Run 1

While the class attributes are well-organized, the methods are severely obfuscated. Functions are named with single letters (a, b, c, d, etc.) and variables use meaningless identifiers (z, A, D, H, K). This destroys clarity of intent, as names like 'get_fieldsets' or 'user' are replaced by 'a' and 'z'. The code structure relies on guesswork rather than logical organization. Several methods exceed manageable length, especially the password change view, which mixes permission checks, form handling, messaging, and response building into one long, deeply nested block. Reading flow is completely unnatural, forcing the reader to trace single-letter variables and decode abbreviated logic. The excessive use of opaque variables and dead single-letter placeholders makes even standard Django admin code nearly unreadable.

Run 2

The code is poorly readable due to deliberately obfuscated method names (a, b, c, d, e, f, g, h) and variables (i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D, E, F, G, H, I, J, K, L, M, N). This destroys clarity of intent and reading flow. While the overall structure is logical and nesting is moderate, the single-letter names make it impossible to understand functionality without reverse-engineering. Action granularity is acceptable, and the code length is reasonable, but these positives are outweighed by the naming choices.

Run 3

This code is severely unreadable due to the use of single-letter or otherwise meaningless variable and method names (a, b, c, g, D, E, F, K, etc.). This destroys clarity of intent, making it impossible to understand the purpose of functions or variables without extensive reverse-engineering. While the code structure mimics Django's standard UserAdmin, the obfuscated identifiers break the reading flow and make the logic appear tangled. The nesting is typical for Django admin views but is exacerbated by unclear variable contexts. Although the code is relatively concise in terms of lines, the cryptic naming negates any benefit. Action granularity and logical organization are present but buried under the poor naming conventions. The comments do little to help, as they reference the intended function of obfuscated methods, highlighting what was lost.

Run 1

Code Structure: Configuration and behavior are logically separated into methods, but opaque method names obscure their roles and intended Django overrides. Nesting: Most methods are shallow; the password-change handler has moderately deep conditional nesting. Clarity of intent: Descriptive configuration keys, framework calls, and helpful comments explain some behavior, but single-letter method names and variables severely hinder understanding. Code length: Most length is justified by configuration and workflow requirements, though the password-change method is lengthy and mixes validation, persistence, messaging, and rendering. Action granularity: Statements generally perform one action per line, and multiline expressions are formatted consistently. Reading flow: Imports, configuration, and methods follow a reasonable sequence, with early returns aiding navigation; however, readers must repeatedly infer variable meanings and trace cryptically named method calls.

Run 2

Code Structure: Imports, configuration, and methods are logically organized, but opaque method names hide their roles and framework relationships. Nesting: Most methods are flat, although the password-change handler has several nested branches and a deeply indented redirect expression. Clarity of intent: Single-letter method and variable names severely obscure requests, users, forms, and context; descriptive API calls, comments, and configuration partially compensate. Code length: Configuration is reasonably concise, but the long password-change method combines validation, persistence, messaging, redirection, and rendering. Action granularity: Statements generally perform one action per line, with readable multiline expressions. Reading flow: Consistent formatting and early returns help, but readers must repeatedly infer identifier meanings and trace calls between cryptically named methods.

Run 3

Code Structure: Imports, declarative configuration, and separate methods provide logical organization, but anonymous method names obscure their roles and expected Django hooks. Nesting: Most methods are flat, although the password-change handler contains moderately deep conditional nesting. Clarity of intent: Descriptive configuration keys, framework calls, and helpful comments explain some behavior, but single-letter parameters and variables substantially undermine understanding. Code length: Configuration is reasonably concise; the password-change handler is long and combines validation, persistence, messaging, redirects, and template preparation. Action granularity: Statements generally perform one action per line, with readable multiline expressions. Reading flow: Consistent formatting and early exits help, but readers must repeatedly infer what names such as C, D, and K represent and trace calls between cryptically named methods. Overall, the layout is readable while identifier choices significantly impair comprehension.