Sample
pyint-ca8abc3ae606-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.874 | 0–1; higher is more readable |
| Mi | 0.266 | 0–1; higher is more readable |
| LLOC | 36 | 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.469 | 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. | 1919.799 | −63.353 |
| Source linesThe number of non-empty source lines. | 84 | +33.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.73 | −7.096 |
Intercept 8.87 + feature contributions = -27.979 (log-odds).
Score = sigmoid(-27.979) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 85 | −1.973 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 61 | +1.373 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 83.862 | +0.762 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.547 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77.165 | +0.441 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 78.976 | +0.32 |
Intercept 0.07 + feature contributions = 1.938 (log-odds).
Score = sigmoid(1.938) = 0.874.
| Score | 0.266 |
|---|
| Score | 36 |
|---|
Run 1
The code is generally readable and well-organized. The class has a clear purpose, the docstring is helpful, and the method logic is logically structured. The assertion statement, however, is somewhat complex and hard to parse, reducing clarity. Nesting is minimal, and most code is at the method level. The `__init__` method contains a few multi-step operations (e.g., building the base URL and path) that are reasonably concise but could be slightly clearer with helper methods. Action granularity is mostly one action per line, but the assertion and URL-building lines bundle multiple operations, slightly reducing readability. Reading flow is natural overall, with imports and method ordering following common patterns.
Run 2
The code is well-structured with clear class hierarchy and logical organization. Imports are grouped and typed. The constructor uses a flat, readable flow with minimal nesting. The base_url construction logic is clearly segmented and well-commented. However, the initial assertion condition is overly complex and hard to parse at a glance, mixing boolean logic with string concatenation. Type hints improve clarity, but the long conditional expression reduces readability. Method-level docstrings are helpful. Overall, the code is maintainable but could benefit from simplifying the assertion into a helper method or clearer conditional blocks.
Run 3
The code is highly readable. It has a clear logical structure: imports are organized, the class has a focused responsibility, and methods are concise. Nesting is minimal — the constructor uses one conditional block with straightforward logic. The intent is well-documented with a thorough docstring explaining parameters and behavior. Code length is appropriate for the functionality; the docstring is verbose but justified by the complexity of parameter interactions. Action granularity is mostly one logical action per line, though the assertion line is long and packs multiple conditions into a single expression, slightly reducing readability. Reading flow is natural: the docstring explains the class, then the constructor proceeds step-by-step from validation to URL construction. Minor improvements could include splitting the assertion into named boolean variables, but overall the code is clean, self-documenting, and easy to follow.
Run 1
Code Structure: Logically organized into a focused class with initialization and a separate serialization method; several unused imports add clutter. Nesting: Mostly shallow, with straightforward conditionals inside the base-URL setup. Clarity of intent: Descriptive names, type annotations, and detailed documentation explain the purpose well, but the compound assertion is difficult to parse, and Flask is not imported in the shown snippet. Code length: Implementation is concise; the lengthy docstring is useful rather than redundant, though the imports are excessive for this excerpt. Action granularity: Statements generally perform one action per line, with sensible multiline formatting for signatures and URL construction. Reading flow: Configuration lookup, URL construction, and superclass initialization follow a natural sequence; the assertion briefly interrupts that flow.
Run 2
Code Structure: Clearly organized into a documented class, initialization logic, and a focused serialization method, though several imports appear unused in this snippet. Nesting: Shallow conditional nesting is easy to follow. Clarity of intent: Descriptive names, type annotations, and comprehensive docstrings explain application-derived defaults; however, the compound assertion is harder to decipher than a straightforward validation condition. Code length: Implementation is reasonably concise, while the extensive documentation adds useful context rather than unnecessary logic. Action granularity: Statements generally perform one action each, with multiline expressions formatted cleanly. Reading flow: Initialization progresses naturally from validation to URL construction and superclass setup. The missing visible Flask import and dense assertion slightly interrupt otherwise smooth reading.
Run 3
Code Structure: Imports, class documentation, initialization, and serialization are logically organized, although several imports appear unused in this excerpt. Nesting: Control flow is shallow, with only a few conditionals inside the base URL construction block. Clarity of intent: Descriptive names, type annotations, and detailed docstrings clearly explain application-derived defaults; however, the compound assertion is unnecessarily difficult to interpret. Code length: Implementation is concise and proportionate to its purpose, though the documentation and imports add substantial length. Action granularity: Statements generally perform one action per line, with sensible multiline formatting for signatures and URL construction. Reading flow: Execution naturally progresses from argument validation through default resolution and URL normalization to superclass initialization. The dense assertion briefly interrupts that flow.