Sample
pyint-c8f19fc9547b-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable |
| Dorn | 0.777 | 0–1; higher is more readable |
| Mi | 0.076 | 0–1; higher is more readable |
| LLOC | 17 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.538 | 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.417 | −6.626 |
Intercept 8.87 + feature contributions = -7.521 (log-odds).
Score = sigmoid(-7.521) = 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. | 103 | +0.857 |
| 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. | 103 | −0.697 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.472 |
| 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.779 | −0.022 |
| 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.25 (log-odds).
Score = sigmoid(1.25) = 0.777.
| Score | 0.076 |
|---|
| Score | 17 |
|---|
Run 1
The code is highly readable with a clear, single-purpose class. It has a flat structure with minimal nesting—only a single conditional inside the __call__ method. The intent is explicit: a validator that checks if a value is an instance of a specified type, raising a descriptive TypeError otherwise. The code is concise, with no unnecessary lines. Action granularity is appropriate; each line performs one logical step, such as constructing the error message or raising the exception. Reading flow is natural, following a top-down progression from imports to class definition and methods. The use of attrs for class definition and f-strings for error messages enhances clarity. Minor deductions only because the type annotation (type = attrib()) could be more explicit, and the error message construction is slightly verbose, but overall it's clean and maintainable.
Run 2
The code is highly readable. Structure is clean, with a single class that has a clear, focused responsibility (instance type validation). Nesting is minimal—only one level inside the __call__ method. Intent is obvious from naming and the docstring. Length is concise with no unnecessary code. Action granularity is appropriate, with one logical action per line in most cases. Reading flow starts with a clear class definition, then validates, then provides a helpful representation. The error message construction is precise and improves debuggability. Minor deductions: the reason for using a callable class is explained but could be slightly more contextual; the TypeError arguments are multi-line but still readable.
Run 3
The code is highly readable. It follows a clear, logical structure with a single class that has a focused purpose. Nesting is minimal, limited to a single if-statement inside the __call__ method. Intent is explicit: validate that a value is an instance of a specified type and raise a descriptive TypeError otherwise. The code is concise with no redundancy. Action granularity is appropriate—each line performs a distinct action, such as checking type, formatting an error message, or raising an exception. Reading flow is natural, moving from method definition to validation logic to error handling, then ending with a clean custom __repr__.
Run 1
Code Structure: Imports and a small validator class are logically organized, though several imports are unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: Class and method names, the isinstance check, and the descriptive error message make the validation purpose clear; the docstring explains the callable-class design rather than the method's behavior. Code length: The implementation is concise, although the multiline exception construction is slightly verbose. Action granularity: Each statement performs one clear action, separating message creation from raising the exception. Reading flow: The code progresses naturally from configuration to validation and representation. Framework-specific decorators and abbreviated parameter names require some background knowledge, but overall readability is high.
Run 2
Code Structure: Imports, class declaration, validation logic, and representation method are logically organized, though several imports are unused in this snippet. Nesting: A single conditional keeps the code shallow and easy to follow. Clarity of intent: Descriptive class and method behavior make the type-checking purpose clear; the docstring explains the callable-class design, though it does not describe validation itself. Code length: The implementation is concise, with slightly verbose formatting of the exception arguments. Action granularity: Each statement performs one clear action, separating message construction from exception raising. Reading flow: The progression from stored type to validation and representation is natural; framework-specific decorators and attributes require some background knowledge.
Run 3
Code Structure: Imports and a single validator class are logically organized, though several imports are unused in this snippet. Nesting: Only one conditional, keeping control flow shallow. Clarity of intent: Descriptive class and method names, a straightforward isinstance check, and an informative error message make the purpose clear; the docstring explains the callable-class design rather than validation behavior. Code length: Compact overall, although the multiline exception construction is somewhat verbose. Action granularity: Each statement performs one clear action. Reading flow: Natural progression from configuration to validation and representation, with minor friction from the long error-message line and framework-specific decorators.