Sample
pyint-468cb5a6293b-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable |
| Dorn | 0.84 | 0–1; higher is more readable |
| Mi | 0.262 | 0–1; higher is more readable |
| LLOC | 17 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.33 | 0–20; mean of three runs |
| BTTF | 0.573 | 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. | 635.312 | −20.965 |
| Source linesThe number of non-empty source lines. | 28 | +11.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.411 | −6.617 |
Intercept 8.87 + feature contributions = -7.512 (log-odds).
Score = sigmoid(-7.512) = 0.001.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.931 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.463 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 26 | +0.162 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 27.739 | −0.022 |
| 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. | 87 | −0.02 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 29 | +0.01 |
Intercept 0.07 + feature contributions = 1.659 (log-odds).
Score = sigmoid(1.659) = 0.84.
| Score | 0.262 |
|---|
| Score | 17 |
|---|
Run 1
The code is well-structured and highly readable. It uses a clear class-based approach for a validator, with a single, focused responsibility. The nesting is minimal, with only one level of indentation in the __call__ method. The intent is obvious: verifying that a value is a subclass of a specified type. The code is concise, with no redundant lines. Action granularity is appropriate—one logical operation per line, such as the issubclass check and the raising of TypeError. Reading flow is natural, moving from imports to class definition to method logic. The use of type hints (e.g., `inst`, `attr`, `value`) and a clear error message further enhances clarity. The only minor deduction is that the `@attrs` decorator and `attrib()` call may be unfamiliar to those not using the `attrs` library, but this is not a code structure issue. Overall, the code is nearly ideal for its purpose.
Run 2
The code is generally well-structured and readable. It uses a class-based validator with clear intent, logical imports, and a concise implementation. The __call__ method is flat with minimal nesting and each major action (type check, error message construction, raise) is separated. The docstring clarifies the design decision for using a callable class. Minor deductions: the error message f-string is slightly long, and the raise statement spans multiple lines, but this is consistent with the error class signature. The __repr__ method is clean and informative. Overall, the code follows idiomatic Python patterns and is easy to follow.
Run 3
The code is well-structured with clear imports and a focused class definition. It uses the attrs decorator to reduce boilerplate, making the code concise. The validator class has a single, clear purpose: checking if a value is a subclass of a given type. Nesting is minimal—only one level—and the error message construction is readable. Each action is on its own line, which improves readability. The __repr__ method is short and purposeful. The docstring explains why a callable class is used, which aids understanding. Minor deductions: the imports could be grouped more conventionally (e.g., third-party vs local), and the regex import is unused, which slightly hurts clarity. Overall, the code is highly readable with clear intent and good organization.
Run 1
Code Structure: Imports and a compact validator class are logically organized, though several imports are unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The class name, subclass check, error message, and custom representation clearly communicate purpose; abbreviated parameters and a docstring focused on implementation rather than validation slightly reduce clarity. Code length: The implementation is concise, although the multiline exception arguments add some visual overhead. Action granularity: Each statement performs one clear action, with message construction separated from raising the exception. Reading flow: The progression from configuration to validation to representation is natural and easy to follow.
Run 2
Code Structure: Imports and a focused validator class are logically organized, although several imports are unused in this snippet. Nesting: Shallow nesting makes the validation branch easy to follow. Clarity of intent: Class naming, issubclass(), and the descriptive error message clearly communicate the purpose; the __call__ docstring explains the callable-class design rather than the method's behavior. Code length: The implementation is concise, though unused imports and the expanded exception arguments add minor clutter. Action granularity: Each statement performs one clear action, with message construction separated from raising the exception. Reading flow: The progression from stored configuration to validation and representation is natural, but understanding attrib(), attrs(), and the unused inst parameter requires familiarity with the surrounding framework.
Run 3
Code Structure: Imports and a small validator class are logically organized, although several imports are unused in this snippet. Nesting: Minimal nesting makes the validation path easy to follow. Clarity of intent: The class name, subclass check, and descriptive error clearly communicate the purpose; the docstring explains the callable-class design rather than the validation itself. Code length: The implementation is concise, though unused imports and the expanded exception arguments add minor clutter. Action granularity: Each statement performs a single clear action. Reading flow: The class moves naturally from its configured type to validation and representation, with only minor formatting distractions.