Sample
pyint-b66b443d6c80-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.01 | 0–1; higher is more readable |
| Dorn | 0.873 | 0–1; higher is more readable |
| Mi | 0.497 | 0–1; higher is more readable |
| LLOC | 17 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.688 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (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. | 422.873 | −13.955 |
| Source linesThe number of non-empty source lines. | 19 | +7.6 |
| 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.708 | −7.062 |
Intercept 8.87 + feature contributions = -4.547 (log-odds).
Score = sigmoid(-4.547) = 0.01.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 64.7 | +0.925 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.035 | +0.6 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 20 | +0.328 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 65 | +0.244 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 18.894 | −0.146 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 19 | −0.08 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 19 | −0.015 |
Intercept 0.07 + feature contributions = 1.927 (log-odds).
Score = sigmoid(1.927) = 0.873.
| Score | 0.497 |
|---|
| Score | 17 |
|---|
Run 1
The code is highly readable, with clear structure and purpose. It begins with a standard import block organized logically (standard library, then typing, then local modules). The `AuthBase` class is simple and explicit, with a clear docstring explaining its role. The `__call__` method is concise and directly raises `NotImplementedError` with a helpful message. One action per line is respected, typing is used, and nesting is minimal. Only minor points are deducted due to the presence of several unused imports and possibly redundant compatibility imports, which slightly affect clarity of intent and code length.
Run 2
This code is highly readable. It has a clear, logical structure with standard imports grouped together and a single, well-defined class. The nesting is minimal, with only one method that clearly states its purpose. The intent is unambiguous: it defines a base class for authentication implementations with a callable interface. The code is concise but not overly so, with just enough context. Each import is on its own line, and within the class, the docstring and method are separated appropriately. The reading flow is natural, going from imports to class definition to method. The use of a docstring and NotImplementedError with a clear message enhances clarity. Only minor improvement could be grouping imports by standard library, third-party, and local modules, but this is a very small concern.
Run 3
The code demonstrates strong structural organization with a clear, single-purpose class definition and logical import grouping (future, stdlib, third-party/local). It maintains flat nesting with no nested control structures, making the flow immediately understandable. Intent is explicit: AuthBase is an abstract base class for authentication, with a clear NotImplementedError message. The code is concise with no unnecessary verbosity, and each action occupies a single line. Reading flow is natural - imports at top, class declaration, docstring, then method. Minor deductions: (1) The unused import hashlib, os, re, threading, time, warnings, and b64encode reduce clarity by suggesting dependency bloat. (2) The type hint 'PreparedRequest' is used without being imported or defined, relying on TYPE_CHECKING which is not properly set up, potentially causing confusion or runtime errors. (3) No abstractmethod decorator, which would more explicitly communicate the abstract nature of the class.
Run 1
Code Structure: Imports precede a clearly defined authentication base class, although many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, docstring, type annotations, and explicit NotImplementedError clearly communicate the authentication hook contract; the parameter name 'r' is less descriptive, and PreparedRequest is not defined or imported in the shown code. Code length: The class is concise, but the extensive import list adds unnecessary reading overhead for this snippet. Action granularity: Each import and statement occupies its own line. Reading flow: The progression from imports to class to method is natural, though additional blank lines between import groups and before the class would improve visual organization.
Run 2
Code Structure: Imports are grouped before a clearly defined base class, though standard-library and local imports lack a separating blank line, and many imports are unused in this snippet. Nesting: Minimal, with only a class and method scope. Clarity of intent: The class name, docstring, type annotations, and explicit NotImplementedError clearly communicate an authentication interface; the parameter name 'r' is less descriptive. Code length: The implementation is concise, although the extensive imports distract from its small purpose. Action granularity: Each import and statement occupies its own line. Reading flow: Straightforward progression from dependencies to class definition to callable contract, with minor friction from the import clutter and PreparedRequest not being defined or imported in the shown code.
Run 3
Code Structure: Imports precede a clearly defined base class, providing logical organization, though many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, docstring, type annotations, and explicit NotImplementedError clearly establish an authentication interface; the parameter name 'r' is less descriptive, and PreparedRequest is not defined or imported here. Code length: The class is concise, but the extensive import block is disproportionate to the shown functionality. Action granularity: Each statement occupies its own line. Reading flow: Execution flows naturally from imports to class to method, although additional blank lines separating import groups and the top-level class would improve visual organization.