Sample
pyint-852621786022-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.851 | 0–1; higher is more readable |
| Mi | 0.467 | 0–1; higher is more readable |
| LLOC | 15 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.645 | 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. | 690.587 | −22.789 |
| Source linesThe number of non-empty source lines. | 27 | +10.8 |
| 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.344 | −6.517 |
Intercept 8.87 + feature contributions = -9.636 (log-odds).
Score = sigmoid(-9.636) = 0.
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. | 70.821 | +0.666 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.41 |
| 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. | 25 | +0.128 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 53.821 | +0.064 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 28 | +0.045 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.875 | −0.034 |
Intercept 0.07 + feature contributions = 1.745 (log-odds).
Score = sigmoid(1.745) = 0.851.
| Score | 0.467 |
|---|
| Score | 15 |
|---|
Run 1
The code is well-structured with clear imports and a single-purpose class. It uses the contextmanager, Pattern, and operator imports though they aren't used in this snippet, which could confuse readers. Nesting is minimal — only one level — and intent is unambiguous: validate callables. The error message formatting is slightly awkward but readable. Action granularity is appropriate, with one logical operation per line. Reading flow is natural: class definition, validator method, then repr. Minor issues: unused imports make the purpose slightly less focused, and the multi-line message construction in the raise call could be cleaner. Overall highly readable.
Run 2
The code is highly readable with clear structure and minimal nested logic. Imports are organized, though `operator`, `re`, and `Pattern` appear unused (minor length/structure issue). The class is small and focused, with a single public method that performs one validation action and raises a specific error. The error message formatting is multi-line and slightly awkwardly indented, but the intent remains clear. The `__repr__` is concise and self-documenting. No deep nesting, good action granularity, and natural reading flow. The docstring inside `__call__` is more of a comment explaining the class design rather than the method behavior, which slightly reduces clarity of intent, but overall this is clean, maintainable code.
Run 3
The code is generally readable with clear structure and intent. It defines a single validator class using a decorator, with a short __call__ method and __repr__ method. Nesting is minimal—only one if statement and one function call. Length is concise. The error message construction is slightly awkward due to line breaks and string concatenation, which reduces clarity. The mix of imports and context managers is not used, which adds slight noise. Overall, the code is easy to follow, with good naming and minimal complexity, but the f-string approach would improve readability further.
Run 1
Code Structure: The validator class is logically organized into validation and representation methods, though several unused imports add clutter. Nesting: Only one conditional is used; the multiline exception construction adds visual complexity without deep control-flow nesting. Clarity of intent: Descriptive class and exception names make the callable-validation purpose clear, although the docstring explains the class design rather than the method's behavior. Code length: The implementation is concise, but unnecessary imports and a blank line before the raise reduce compactness. Action granularity: Each statement performs a distinct action; multiline formatting keeps the exception arguments readable. Reading flow: Validation proceeds naturally from the callable check to a descriptive error, followed by a simple representation method. The split error string and nested formatting slightly interrupt otherwise straightforward reading.
Run 2
Code Structure: The validator class cleanly separates validation from its representation, although several imports appear unused in this snippet. Nesting: Control flow is shallow, with only one conditional; the multiline exception construction adds some visual complexity. Clarity of intent: The class name, callable check, and descriptive error message make the purpose clear, though the docstring explains the design rather than the validation behavior, and inst is unused. Code length: The implementation is concise, but unused imports and an extra blank line add clutter. Action granularity: Each statement performs one clear action, and the exception arguments are laid out readably. Reading flow: The sequence from imports to class, validation, and representation is natural; spacing around the class and the awkwardly wrapped message slightly reduce polish.
Run 3
Code Structure: The validator class cleanly separates validation from its representation, though several imports are unused in this snippet. Nesting: A single conditional keeps control flow shallow; the nested formatting expression adds minor visual complexity. Clarity of intent: The class name, callable check, and specific exception clearly communicate the purpose. The docstring explains the callable-class design, although abbreviated parameters such as inst and attr are less descriptive. Code length: The implementation is concise, but unused imports and an unnecessary blank line add clutter. Action granularity: Each statement performs a distinct action; multiline exception construction remains cohesive. Reading flow: Execution proceeds naturally from the callable check to exception creation, followed by representation behavior. Splitting the error-message string and formatting across several lines slightly interrupts the flow.