Sample
pyint-8c0a398c606d-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.831 | 0–1; higher is more readable |
| Mi | 0.26 | 0–1; higher is more readable |
| LLOC | 17 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.617 | 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. | 578.587 | −19.093 |
| Source linesThe number of non-empty source lines. | 23 | +9.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.609 | −6.914 |
Intercept 8.87 + feature contributions = -7.937 (log-odds).
Score = sigmoid(-7.937) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.917 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.46 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 24 | +0.187 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 22.784 | −0.091 |
| 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.958 | −0.018 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 21 | −0.011 |
Intercept 0.07 + feature contributions = 1.592 (log-odds).
Score = sigmoid(1.592) = 0.831.
| Score | 0.26 |
|---|
| Score | 17 |
|---|
Run 1
The code is highly readable. It is well-structured, using a frozen/slotted attrs class for a simple validator, and imports are grouped logically. Nesting is minimal, with only one shallow conditional. The intent is very clear: enforce a maximum length. The code is concise and avoids unnecessary verbosity. Action granularity is good, with the message construction and exception raising on separate lines. Reading flow is natural, with the callable logic followed by the repr override. Minor deductions: the docstring explains why a callable class is used but could be slightly more prominent, and the lambda-like simplicity means no complex structure is present to compare against; overall, it is an excellent example of clean, idiomatic Python.
Run 2
The code is well-structured and readable. It uses clear imports, a single-purpose frozen attrs class, and a concise validation method. The logic is flat with minimal nesting (one if statement). Intent is obvious from the class name, docstring, and meaningful variable names like `max_length`, `inst`, `attr`, and `value`. The error message is explicit. Action granularity is appropriate: one logical step per line. Reading flow is natural—imports, class definition, method, then repr. Minor deductions: the docstring only explains why a callable class is used, not what the validator does; `inst` is unused; and the import block is slightly long relative to the code’s size. Overall, it is clean, idiomatic Python that would be easily understood by most developers.
Run 3
The code is well-structured and highly readable. It uses a frozen, slotted attrs class for a simple validator, which clearly communicates intent. The __call__ method is flat, with a single, clear conditional and a concise error message. Functionality is focused, and the repr override aids debugging. Imports are specific, and the regex/contextmanager imports are slightly extraneous but not harmful. One minor deduction for unnecessary imports that could confuse intent, but overall the logic is crisp, with one action per line and natural flow.
Run 1
Code Structure: The validator is logically organized into configuration, validation, and representation methods, although several imports are unused in this snippet. Nesting: A single conditional keeps the code flat and easy to follow. Clarity of intent: Descriptive class and attribute names, along with an informative error message, make the maximum-length constraint clear; the __call__ docstring explains the class design rather than the method's behavior. Code length: The implementation is concise, with little unnecessary code beyond the imports. Action granularity: Each line performs one clear action, and message construction is separated from raising the exception. Reading flow: The progression from the length limit to validation and representation is natural, though framework-specific decorators and attrib() require some background knowledge.
Run 2
Code Structure: The validator is logically organized into configuration, validation, and representation methods, though many unused imports add clutter. Nesting: A single conditional keeps the code flat and easy to follow. Clarity of intent: Descriptive class and attribute names make the length constraint clear, and the error message is informative; the callable method's docstring explains a design choice rather than its validation behavior. Code length: The implementation is concise, but the import section is excessive for this snippet. Action granularity: Each statement performs one clear action. Reading flow: The progression from declaring the limit to checking it and defining its representation is natural. Minor spacing improvements around imports and the class would improve visual separation.
Run 3
Code Structure: The validator class logically groups its configuration, validation behavior, and representation, although several unused imports add clutter. Nesting: A single conditional keeps the code shallow and easy to follow. Clarity of intent: Descriptive class and attribute names make the length constraint clear, and the error message is informative; the __call__ docstring explains the callable-class design rather than the method's validation behavior. Code length: The implementation is concise, though the imports could be reduced. Action granularity: Each line performs one clear action. Reading flow: Configuration, validation, and representation appear in a natural order, with whitespace separating methods.