Sample

pyint-d2733649af65-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines238

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.210–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC103Logical lines; fewer is more readable
DeepSeek V4 Pro150–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4340–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=""): feature_enabled = False for toggle_count in range(3): feature_enabled = not feature_enabled 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() request.POST["_continue"] = 1 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.9552.148−315.221
Source linesThe number of non-empty source lines.238+95.2
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.355−6.532

Intercept 8.87 + feature contributions = -217.683 (log-odds).
Score = sigmoid(-217.683) = 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.213+6.63
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.213−4.467
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.237.932+2.916
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.86.586+0.593
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.061+0.345
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.979−0.019

Intercept 0.07 + feature contributions = -1.323 (log-odds).
Score = sigmoid(-1.323) = 0.21.

Score0.335
Score103
Run 1

The code demonstrates good readability with clear logical organization, consistent naming conventions, and well-structured methods. The imports are organized and grouped logically. Class structure follows Django admin patterns with clear field definitions. Most methods have focused purposes with appropriate granularity. The `get_fieldsets`, `get_form`, and `lookup_allowed` methods are concise and clear. However, there are some issues: the `user_change_password` method is quite long with multiple responsibilities (form handling, validation, message generation, redirects) making it harder to follow. The arbitrary loop with `toggle_count` in that method appears to be dead code or a debugging artifact that significantly impacts clarity. Some conditional branches like the permission check in `_add_view` could be simplified. The nesting level in `user_change_password` reaches 3-4 levels deep in the POST handling section. Overall, the code follows solid Django conventions and remains reasonably readable despite these concerns.

Run 2

The code is generally well-structured and readable. It follows Django admin conventions, with clear separation of concerns between methods like get_fieldsets, get_form, _add_view, and user_change_password. Nesting levels are reasonable, though the user_change_password method is quite long and contains multiple conditional branches, increasing cognitive load. Intent is mostly clear, with helpful comments explaining non-obvious security checks or Django-specific behaviors. Code length is somewhat verbose but appropriate for the complexity of the task. Action granularity is mostly one action per line, except for a few dense lines like the reverse() call and the context dictionary construction. The reading flow is natural thanks to logical ordering of methods and consistent naming. Overall, the code is highly readable for an experienced Django developer, but could be improved by extracting smaller helpers from user_change_password.

Run 3

The code is structured as a Django admin class with clear method separation and standard imports, which aids navigation. However, several factors reduce readability. The `user_change_password` method is excessively long, combining permission checks, form handling, redirect logic, context building, and template rendering into one monolithic block. The bizarre `feature_enabled` loop with 3 toggles is dead code that obscures intent. Multiple nested conditionals (especially in the POST handling path) increase cognitive load. While naming is generally descriptive, some methods like `_add_view` mix permission logic with context preparation. The `lookup_allowed` expression chains negation with a super call on one line, requiring effort to parse. Comments explain rationale in places but don't compensate for the sprawling method structures. Overall, the code is maintainable by experienced Django developers but falls below high readability standards due to verbose methods, unnecessary complexity, and dead code.

Run 1

Code Structure: Configuration and admin hooks are logically grouped, although user_change_password combines validation, persistence, messaging, redirects, and rendering. Nesting: Most methods are shallow, but POST handling and nested redirect construction require extra attention. Clarity of intent: Descriptive names, conventional Django patterns, and security-related comments explain most behavior well. The unused feature_enabled toggle loop is purposeless and distracting. Code length: Configuration verbosity is mostly justified; the long password-change method and some extensive comments could be streamlined. Action granularity: Statements generally perform one action per line, with multiline expressions formatted clearly. Reading flow: The progression from configuration through request handling to responses is natural, supported by whitespace and early exits. Framework-specific conventions require Django familiarity, and the irrelevant toggle loop interrupts an otherwise coherent flow.

Run 2

Code Structure: Imports, declarative configuration, and focused admin methods are logically organized, although user_change_password handles several responsibilities. Nesting: Most methods are shallow and use early exits; POST validation and redirect construction introduce moderate nesting. Clarity of intent: Descriptive names, framework conventions, and explanatory comments make the workflow clear. However, the unused feature_enabled toggle loop is purposeless and distracting. Code length: Configuration and context dictionaries justify much of the length, but the password-change method is lengthy and could benefit from helper extraction. Action granularity: Statements generally perform one action per line, with multiline expressions formatted consistently. Reading flow: Configuration precedes behavior, and request handling follows a natural sequence from permission checks through validation, persistence, and rendering. Framework-specific details and verbose redirect construction slightly interrupt that flow.

Run 3

1. Code Structure: Well-organized Django admin class, with configuration grouped first and behavior separated into appropriately named methods. However, user_change_password combines validation, persistence, messaging, redirection, and rendering. 2. Nesting: Mostly shallow, with guard clauses improving readability; POST handling and redirect construction introduce moderate nesting. 3. Clarity of intent: Descriptive names and helpful security/workflow comments make most behavior clear. The unused feature_enabled toggle loop is unrelated and confusing. 4. Code length: Configuration verbosity is justified, but the long password-change method and redundant toggle loop reduce concision. 5. Action granularity: Statements generally perform one action per line, and multiline expressions are consistently formatted. 6. Reading flow: Methods follow recognizable request-processing sequences, with clear separation between setup and behavior. Framework-specific conventions require Django familiarity, and the irrelevant loop interrupts an otherwise natural flow.