Sample

pyint-784fcf2c7e09-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines126

Scores

MethodScoreScale
Posnett0.0010–1; higher is more readable
Dorn0.5230–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC35Logical lines; fewer is more readable
DeepSeek V4 Pro6.330–20; mean of three runs
GPT-6.1 Sol9.330–20; mean of three runs
BTTF0.5760–1; higher is more readable

Views

Source code

from __future__ import annotations import typing as t from . import typing as ft from .globals import current_app from .globals import request class View: """Subclass this class and override :meth:`dispatch_request` to create a generic class-based view. Call :meth:`as_view` to create a view function that creates an instance of the class with the given arguments and calls its ``dispatch_request`` method with any URL variables. See :doc:`views` for a detailed guide. .. code-block:: python class Hello(View): init_every_request = False def dispatch_request(self, name): return f"Hello, {name}!" app.add_url_rule( "/hello/<name>", view_func=Hello.as_view("hello") ) Set :attr:`methods` on the class to change what methods the view accepts. Set :attr:`decorators` on the class to apply a list of decorators to the generated view function. Decorators applied to the class itself will not be applied to the generated view function! Set :attr:`init_every_request` to ``False`` for efficiency, unless you need to store request-global data on ``self``. """ #: The methods this view is registered for. Uses the same default #: (``["GET", "HEAD", "OPTIONS"]``) as ``route`` and #: ``add_url_rule`` by default. methods: t.ClassVar[t.Collection[str] | None] = None #: Control whether the ``OPTIONS`` method is handled automatically. #: Uses the same default (``True``) as ``route`` and #: ``add_url_rule`` by default. provide_automatic_options: t.ClassVar[bool | None] = None #: A list of decorators to apply, in order, to the generated view #: function. Remember that ``@decorator`` syntax is applied bottom #: to top, so the first decorator in the list would be the bottom #: decorator. #: #: .. versionadded:: 0.8 decorators: t.ClassVar[list[t.Callable[..., t.Any]]] = [] #: Create a new instance of this view class for every request by #: default. If a view subclass sets this to ``False``, the same #: instance is used for every request. #: #: A single instance is more efficient, especially if complex setup #: is done during init. However, storing data on ``self`` is no #: longer safe across requests, and :data:`~flask.g` should be used #: instead. #: #: .. versionadded:: 2.2 init_every_request: t.ClassVar[bool] = True def dispatch(self) -> ft.ResponseReturnValue: """The actual view function behavior. Subclasses must override this and return a valid response. Any variables from the URL rule are passed as keyword arguments. """ raise NotImplementedError() @classmethod def as2( cls, nam: str, *class2: t.Any, **class3: t.Any ) -> ft.RouteCallable: """Convert the class into a view function that can be registered for a route. By default, the generated view will create a new instance of the view class for every request and call its :meth:`dispatch_request` method. If the view class sets :attr:`init_every_request` to ``False``, the same instance will be used for every request. Except for ``name``, all other arguments passed to this method are forwarded to the view class ``__init__`` method. .. versionchanged:: 2.2 Added the ``init_every_request`` class attribute. """ if cls.init_every_request: def view(**kwa: t.Any) -> ft.ResponseReturnValue: sel2 = view.view_class( # type: ignore[attr-defined] *class_args, **class_kwargs ) return current_app.ensure_sync(sel2.dispatch)(**kwa) # type: ignore[no-any-return] else: sel = cls(*class2, **class3) # pyright: ignore def view(**kwa2: t.Any) -> ft.ResponseReturnValue: return current_app.ensure_sync(self.dispatch)(**kwa2) # type: ignore[no-any-return] if cls.decorators: vie.__name__ = nam vie.__module__ = cls.__module__ for dec in cls.decorators: vie = dec(vie) # We attach the view class to the view function for two reasons: # first of all it allows us to easily figure out what class-based # view this thing came from, secondly it's also used for instantiating # the view class so you can actually replace it with something else # for testing purposes and debugging. vie.view_class = cls # type: ignore vie.__name__ = nam vie.__doc__ = cls.__doc__ vie.__module__ = cls.__module__ vie.methods = cls.methods # type: ignore vie.provide_automatic_options = cls.provide_automatic_options # type: ignore return vie

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.1812.586−59.815
Source linesThe number of non-empty source lines.126+50.4
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.512−6.768

Intercept 8.87 + feature contributions = -7.314 (log-odds).
Score = sigmoid(-7.314) = 0.001.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.127−3.46
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.125.881+1.35
Indentation frequencyHow rapidly indentation changes from line to line.46+0.854
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.99.969+0.809
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.031+0.643
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.99.984−0.57
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.094 (log-odds).
Score = sigmoid(0.094) = 0.523.

Score0.464
Score35
Run 1

The code has severe readability issues. Structure is disjointed: the method is named `as2`, but references `view` and `vie` inconsistently, with undefined variables like `class_args` and `class_kwargs`. Nesting is moderate but muddled by ambiguous logic. Intent is confusing — the class attributes are documented well, but the implementation contradicts names (`dispatch` vs expected `dispatch_request`, `self` used inside a static-like view function). Code length is verbose due to excessive comments, yet the actual logic is incomplete and broken. Action granularity is poor: multiple operations occur per line, mixing assignments, calls, and type ignores. Reading flow is unnatural, jumping between `vie`, `view`, and `sel`. The overall effect is unreadable, error-prone code that fails to clearly express its purpose or function correctly.

Run 2

The code has serious readability issues. Variable names are confusing and inconsistent ('as2', 'nam', 'sel', 'sel2', 'vie', 'kwa', 'kwa2'), and there are apparent bugs (undefined variables 'class_args'/'class_kwargs', inconsistent use of 'view_class' vs 'cls', 'self.dispatch' used instead of 'sel.dispatch'). The conditional branch creates server-side view instances with parallel but non-uniform code, and the decorator/attribute-assignment section is disconnected from the view function definition. While the class-level docstrings are clear, the method implementation lacks coherent structure and natural reading flow. Action granularity is poor; multiple concerns are packed into single expressions. The nesting is shallow, but clarity of intent is undermined by poor naming and unclear variable references. Overall, this code is difficult to read, understand, and maintain.

Run 3

The code has a clear overall class structure with good docstrings, but it contains several critical readability issues. The method `as2` uses confusing parameter names (`class2`, `class3`) that obscure intent, and there are undefined or inconsistent variable names (`class_args`, `class_kwargs`, `sel2`, `self.dispatch` inside the else branch, `vie` vs `view`). The conditional logic splits into two branches that create different view functions, increasing cognitive complexity. Some lines perform multiple actions or contain long comments that break flow. The docstrings are informative but oversized relative to the code they describe, adding visual clutter. While the concepts are understandable, the implementation details and naming inconsistencies undermine clarity.

Run 1

Code Structure: Class attributes and methods are logically organized, but inconsistent identifiers undermine coherence. Nesting: Moderate nesting in conditional function definitions and the decorator loop remains manageable. Clarity of intent: Detailed documentation explains the intended design, but names such as as2, nam, class2, sel2, and vie are unclear. References to undefined class_args, class_kwargs, self, and vie force readers to infer intended relationships. Documentation also refers to dispatch_request and as_view rather than the implemented dispatch and as2. Code length: Implementation is reasonably concise, though extensive documentation outweighs the executable code. Action granularity: Most lines perform one clear action, with no compressed multi-statement lines. Reading flow: The progression from configuration to dispatch to view generation is natural, but naming mismatches, inconsistent references, and long inline type-ignore comments repeatedly interrupt comprehension.

Run 2

Code Structure: Class attributes and methods are logically organized, but inconsistent identifiers undermine cohesion. Nesting: Mostly shallow, with manageable conditional branches, nested functions, and a decorator loop. Clarity of intent: Documentation explains the intended behavior, but names such as as2, nam, class2, sel2, and vie obscure meaning. References to undefined class_args, class_kwargs, self, and vie make execution difficult to follow; documentation also refers to dispatch_request and as_view rather than the implemented methods. Code length: Implementation is reasonably concise, although extensive documentation dominates and includes misleading references. Action granularity: Most lines perform one clear action, with only moderately dense callable expressions. Reading flow: The progression from configuration to dispatch and view creation is natural, but mismatched names and repeated metadata assignments force readers to reconstruct the intended relationships.

Run 3

Code Structure: Class attributes, dispatch behavior, and view creation are logically grouped, but inconsistent identifiers disrupt coherence. Nesting: Moderate and manageable, with nested functions inside an if/else and a decorator loop. Clarity of intent: Documentation explains the intended design, but names such as as2, class2, sel2, and vie are ambiguous. Undefined references including class_args, class_kwargs, self, and vie make the implementation difficult to follow, while documentation references methods absent from the code. Code length: Implementation is reasonably concise, although extensive documentation adds scanning overhead and conflicts with actual names. Action granularity: Most lines perform one clear operation; chained calls remain understandable. Reading flow: The overall sequence is natural, but mismatched names repeatedly force readers to infer relationships and intended behavior.