Sample
pyint-09592bd9b132-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.808 | 0–1; higher is more readable |
| Mi | 0.165 | 0–1; higher is more readable |
| LLOC | 18 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.561 | 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. | 652.329 | −21.527 |
| Source linesThe number of non-empty source lines. | 29 | +11.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.388 | −6.582 |
Intercept 8.87 + feature contributions = -7.639 (log-odds).
Score = sigmoid(-7.639) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96 | +0.744 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.459 |
| 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. | 96 | −0.401 |
| 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. | 27 | +0.197 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 30 | −0.026 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.763 | −0.008 |
Intercept 0.07 + feature contributions = 1.434 (log-odds).
Score = sigmoid(1.434) = 0.808.
| Score | 0.165 |
|---|
| Score | 18 |
|---|
Run 1
The code is well-structured and readable. It follows a clear logical organization, with a focused class definition and minimal nesting. The intent is immediately understandable: a validator that checks if a value matches a regular expression. Variable names are descriptive ('pattern', 'match_func', 'inst', 'attr', 'value'). The error message is informative and includes relevant context. The __repr__ method clearly summarizes the validator. The only minor deductions are for slight verbosity in the docstring (attribution is implicit) and the somewhat compressed conditional raise, although it remains clear. Overall, the code is concise, easy to follow, and maintains a natural reading flow.
Run 2
The code is well-structured and readable. It clearly defines a frozen attrs class with a single responsibility: regex validation. The __call__ method has a flat structure with minimal nesting, and the error message construction is clear. The code is concise without unnecessary verbosity. Each line focuses on a single action, enhancing readability. The reading flow is natural, with logical imports and a coherent class definition. Minor deductions: using 'inst' as an unused parameter is slightly ambiguous, and the multiline ValueError call adds some visual complexity. Overall, it's straightforward and maintainable.
Run 3
The code is highly readable due to its logical structure, flat nesting, and clear intent. The use of a frozen, slotted attrs class with a clear name (_MatchesReValidator) immediately communicates its purpose. The __call__ method is concise: it performs a single validation check, constructs a clear error message, and raises a ValueError with relevant context. Action granularity is mostly one action per line, especially in the error-raising block. The __repr__ method aids debugging. Minor deductions: the import of operator and re is unused, and the use of a contextmanager import is irrelevant. Also, the pattern is passed to the exception but not clearly explained in the code itself. Overall, the code follows idiomatic Python practices and reads naturally.
Run 1
Code Structure: The small validator class logically groups its state, validation behavior, and representation, though several imports are unused in this snippet. Nesting: A single conditional keeps control flow shallow. Clarity of intent: Class and method names, the regex check, and the descriptive error message communicate the purpose clearly; however, the call-method docstring explains the class design rather than validation behavior. Code length: The implementation is concise, although the multiline exception construction is somewhat verbose. Action granularity: Each statement performs a distinct action, separating message construction from raising the exception. Reading flow: Imports, class attributes, validation, and representation follow a natural sequence, with minor spacing inconsistencies and unused imports adding visual noise.
Run 2
Code Structure: The validator class is logically organized, with attributes followed by validation and representation methods; several unused imports add clutter. Nesting: A single conditional keeps control flow shallow and easy to follow. Clarity of intent: Descriptive names and an informative error message make regex validation clear, though the __call__ docstring explains the class design rather than the method's behavior. Code length: The implementation is concise, although the multiline exception construction is somewhat verbose. Action granularity: Each statement performs one clear action, with message construction separated from raising the exception. Reading flow: Execution flows naturally from checking the value to reporting failure, followed by the representation method; additional spacing between imports and the class would improve visual separation.
Run 3
Code Structure: The validator is logically organized, with attributes, validation behavior, and representation clearly separated; several 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 regex validation clear, although the __call__ docstring explains the class design rather than the method's behavior. Code length: The implementation is concise, with slightly verbose formatting for the exception arguments. Action granularity: Each statement performs one clear action. Reading flow: The progression from configuration to validation to representation is natural, though a blank line between imports and the decorated class would improve visual separation.