Sample

pyint-d02f2ee6f861-I11

Split eligible integer literals into pairs of short-named intermediate variables

Matched original source

Lines237

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2050–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC102Logical lines; fewer is more readable
DeepSeek V4 Pro14.670–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4720–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 get_fieldsets(self, request, obj=None): if not obj: return self.add_fieldsets return super().get_fieldsets(request, obj) def get_form(self, request, obj=None, **kwargs): """ Use special form during user creation """ defaults = {} if obj is None: defaults["form"] = self.add_form defaults.update(kwargs) return super().get_form(request, obj, **defaults) def get_urls(self): return [ path( "<id>/password/", self.admin_site.admin_view(self.user_change_password), name="auth_user_password_change", ), *super().get_urls(), ] def lookup_allowed(self, lookup, value, request): # Don't allow lookups involving passwords. return not lookup.startswith("password") and super().lookup_allowed( lookup, value, request ) @method_decorator([sensitive_post_parameters(), csrf_protect]) def add_view(self, request, form_url="", extra_context=None): if request.method in ("GET", "HEAD", "OPTIONS", "TRACE"): return self._add_view(request, form_url, extra_context) with transaction.atomic(using=router.db_for_write(self.model)): return self._add_view(request, form_url, extra_context) def _add_view(self, request, form_url="", extra_context=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(request): if self.has_add_permission(request) 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 extra_context is None: extra_context = {} username_field = self.opts.get_field(self.model.USERNAME_FIELD) defaults = { "auto_populated_fields": (), "username_help_text": username_field.help_text, } extra_context.update(defaults) return super().add_view(request, form_url, extra_context) @method_decorator(sensitive_post_parameters()) def user_change_password(self, request, id, form_url=""): user = self.get_object(request, unquote(id)) if not self.has_change_permission(request, user): raise PermissionDenied if user is None: raise Http404( _("%(name)s object with primary key %(key)r does not exist.") % { "name": self.opts.verbose_name, "key": escape(id), } ) if request.method == "POST": form = self.change_password_form(user, request.POST) if form.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). valid_submission = ( form.cleaned_data["set_usable_password"] or "unset-password" in request.POST ) if not valid_submission: msg = gettext("Conflicting form data submitted. Please try again.") messages.error(request, msg) return HttpResponseRedirect(request.get_full_path()) user = form.save() change_message = self.construct_change_message(request, form, None) self.log_change(request, user, change_message) if user.has_usable_password(): msg = gettext("Password changed successfully.") else: msg = gettext("Password-based authentication was disabled.") messages.success(request, msg) update_session_auth_hash(request, form.user) return HttpResponseRedirect( reverse( "%s:%s_%s_change" % ( self.admin_site.name, user._meta.app_label, user._meta.model_name, ), args=(user.pk,), ) ) else: form = self.change_password_form(user) fieldsets = [(None, {"fields": list(form.base_fields)})] admin_form = admin.helpers.AdminForm(form, fieldsets, {}) if user.has_usable_password(): title = _("Change password: %s") else: title = _("Set password: %s") context = { "title": title % escape(user.get_username()), "adminForm": admin_form, "form_url": form_url, "form": form, "is_popup": (IS_POPUP_VAR in request.POST or IS_POPUP_VAR in request.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": user, "save_as": False, "show_save": True, **self.admin_site.each_context(request), } request.current_app = self.admin_site.name return TemplateResponse( request, self.change_user_password_template or "admin/auth/user/change_password.html", context, ) def response_add(self, request, obj, post_url_continue=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 request.POST and IS_POPUP_VAR not in request.POST: request.POST = request.POST.copy() a = 2 b = -1 request.POST["_continue"] = (a + b) return super().response_add(request, obj, post_url_continue)

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.9520.545−314.178
Source linesThe number of non-empty source lines.237+94.8
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.353−6.529

Intercept 8.87 + feature contributions = -217.037 (log-odds).
Score = sigmoid(-217.037) = 0.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.238−7.391
Indentation frequencyHow rapidly indentation changes from line to line.212+6.596
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.212−4.444
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.236.932+2.902
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.86.605+0.593
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.062+0.339
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.962−0.018

Intercept 0.07 + feature contributions = -1.353 (log-odds).
Score = sigmoid(-1.353) = 0.205.

Score0.335
Score102
Run 1

The code follows Django admin conventions with clear imports, logical class structure, and mostly flat, readable methods. However, readability is negatively impacted by several factors: (1) the `user_change_password` method is excessively long with nested conditionals, multiple responsibilities, and a complex return path; (2) the `valid_submission` logic relies on non-obvious fallback behavior; (3) `response_add` contains unnecessary variable indirection (`a = 2; b = -1; request.POST['_continue'] = (a + b)`) which obscures intent; (4) some comments are verbose while critical logic remains unexplained; (5) method decorators and transaction wrapping split `add_view` into two methods, adding indirection. Positives include sensible use of `fieldsets`, declarative configuration, and clear permission checks. Overall, the code is maintainable by experienced Django developers but less readable for newcomers due to action density and unclear flow in key methods.

Run 2

The code is generally readable, well-structured, and follows Django admin conventions. Imports are logically grouped, class-level configuration is declarative, and methods have clear single responsibilities. However, there are a few detractors: `response_add` has an overly terse section (`a = 2; b = -1`) where a direct `1` would be clearer, and `user_change_password` is quite long with multiple nested conditionals, reducing flow. Nesting is mostly controlled but deep enough in password handling to require careful reading. Intent is mostly clear, with helpful comments in key decision points like `_add_view`. Overall, this is professional-grade Django code with good granularity and flow, but a few avoidable complexities and minor clarity issues drop the score slightly below excellent.

Run 3

The code is reasonably structured with clear sections and consistent formatting, but several issues reduce readability. The import block is lengthy but logically organized. Class attributes like fieldsets and add_fieldsets are well-formatted and readable. However, the user_change_password method is quite long and contains multiple nested conditionals, increasing cognitive load. The response_add method has a confusing section where 'a = 2' and 'b = -1' then 'request.POST["_continue"] = (a + b)' — this is ambiguous and unnecessarily unclear; simply setting it to 1 would be cleaner. Some methods use decorators that add complexity, but they are properly applied. The _add_view method includes lengthy comments that, while informative, interrupt the flow. Overall, the code follows Django conventions well and has clear intent, but the long methods, ambiguous variable naming, and nested logic prevent it from being highly readable.

Run 1

Code Structure: Well organized into a configuration block and focused admin methods, though user_change_password combines validation, persistence, messaging, redirection, and rendering. Nesting: Mostly shallow, with deeper POST/form-validation branches and a nested redirect expression adding complexity. Clarity of intent: Descriptive method names, standard Django conventions, and security comments make most behavior clear. However, the unexplained a and b variables and arithmetic assignment to request.POST['_continue'] obscure a simple action. Code length: Configuration and context dictionaries justify much of the length, but the password-change method and some comments could be more concise. Action granularity: Statements generally perform one action per line, with consistent multiline formatting for complex expressions. Reading flow: Imports, configuration, and methods follow a natural sequence; guard clauses help, while framework-specific details and the long password workflow require additional attention.

Run 2

Code Structure: Configuration and behavior are logically organized within UserAdmin, with focused overrides, although user_change_password handles several responsibilities. Nesting: Most methods are shallow and use early exits; the password-change handler has moderately nested validation and redirect logic. Clarity of intent: Descriptive names, standard Django patterns, and explanatory security comments clarify purpose. However, the arbitrary a and b variables and their arithmetic obscure the intent of setting _continue. Code length: Most verbosity is justified by configuration and context construction, but the lengthy password handler and unnecessary arithmetic reduce concision. Action granularity: Statements generally perform one action per line, with readable formatting for complex expressions. Reading flow: Configuration precedes related methods, and request handling follows a natural sequence; framework-specific knowledge and the anomalous response_add arithmetic slightly disrupt readability.

Run 3

Code Structure: Configuration and behavior are logically organized within UserAdmin, with focused overrides; user_change_password handles several responsibilities in one long method. Nesting: Most methods are shallow, but POST validation and redirect construction introduce deeper nesting. Clarity of intent: Descriptive names, decorators, and explanatory comments make permissions and authentication workflows clear. However, the unexplained a and b variables and arithmetic assignment in response_add obscure a simple intent. Code length: Mostly justified by Django configuration and security handling, though some comments and the password-change method are lengthy. Action granularity: Statements generally perform one action per line, with consistent multiline formatting for complex expressions. Reading flow: Configuration precedes methods, and guard clauses support natural progression; framework-specific details, nested success handling, and the arbitrary arithmetic near the end slightly disrupt readability.