Sample
int-b14c5bd4c6eb-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.511 | 0–1; higher is more readable |
| Dorn | 0.356 | 0–1; higher is more readable |
| Mi | 0.281 | 0–1; higher is more readable |
| LLOC | 14 | 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.618 | 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. | 2531.532 | −83.541 |
| Source linesThe number of non-empty source lines. | 79 | +31.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. | 5.158 | −7.737 |
Intercept 8.87 + feature contributions = -50.807 (log-odds).
Score = sigmoid(-50.807) = 0.
| Score | 0.511 |
|---|
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. | 169.988 | −3.535 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 170 | +1.938 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 80 | −1.796 |
| 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. | 78.924 | +0.693 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.07 | +0.265 |
Intercept 0.07 + feature contributions = -0.593 (log-odds).
Score = sigmoid(-0.593) = 0.356.
| Score | 0.281 |
|---|
| Score | 14 |
|---|
Run 1
The code is well-structured and highly readable. It has a clear class hierarchy, logical organization with constructors and overridden methods, and minimal nesting. Each method has a single, clear purpose, and the actions are concise—one primary operation per line. The use of Javadoc comments and meaningful method names (e.g., canDecode, decode) enhances clarity of intent. The code length is appropriate, avoiding unnecessary verbosity while maintaining completeness. Reading flow is natural: the constructors lead to the overridden methods, each returning or throwing clear exceptions. Minor deductions include slightly long import statements and a single-line method that could be more readable if split, but overall the code is highly maintainable and understandable.
Run 2
The code demonstrates strong readability. Structure is logical with clear class-level documentation and separated constructors. Nesting is minimal. Intent of each method is explicit, especially the stream-decoding limitation. Length is appropriate, with no unnecessary verbosity. Most lines perform a single action, and the try/finally cleanly isolates resource release. Minor deductions: the parameter list in the 'decode' method is long but acceptable; the override annotation on a throwing method is slightly unusual. Overall, the class is easy to follow and maintain.
Run 3
The code is well-structured, with clear class-level documentation explaining its purpose and limitations. Imports are organized and the class hierarchy is logical. Methods are concise, serve single purposes, and follow standard naming conventions. Nesting is minimal: the only nested block is a try-finally with a single statement each. Intent is evident from method names and the Javadoc. Exception handling and resource release are handled correctly in the finally block. Minor readability deductions: the overridden decode method signature is somewhat long due to multiple parameters and annotations, and the method throws UnsupportedOperationException with minimal elaboration, though the class-level Javadoc covers it. Overall, the code is highly readable.
Run 1
Code Structure: Well organized into constants, state, constructors, and decoder overrides, with helpful documentation. Nesting: Minimal nesting; the try/finally block is straightforward. Clarity of intent: Descriptive names and explicit documentation clearly explain JSON decoding and unsupported streaming. Code length: Concise implementation with proportionate documentation, though long method signatures reduce scanability. Action granularity: Statements generally perform one action per line; the nested reader construction and parsing expression slightly compress multiple operations. Reading flow: Natural progression from configuration to capability checks and decoding, with explicit buffer cleanup. Minor formatting issues, including ungrouped imports and long lines, prevent a top score.
Run 2
Code Structure: Well organized into constants, a dependency field, constructors, capability checking, and decoding methods. Nesting: Minimal, with only a straightforward try/finally block. Clarity of intent: Descriptive names and useful Javadoc clearly explain JSON conversion and the unsupported streaming mode. Code length: Concise, with little unnecessary implementation code. Action granularity: Most lines perform one clear action, although reader creation, stream access, and deserialization are combined in one expression. Reading flow: Conventional class organization and explicit buffer cleanup make the implementation easy to follow. Minor readability drawbacks include long method signatures, tightly packed imports, and the need to distinguish two overloaded decode methods.
Run 3
Code Structure: Logically organized into constants, state, constructors, and decoder overrides. Nesting: Minimal; the only control structure is a straightforward try/finally. Clarity of intent: Descriptive names and useful documentation clearly explain Gson decoding and the unsupported streaming operation. Code length: Concise implementation with proportionate documentation, though method signatures are long. Action granularity: Statements generally perform one action each; the nested reader creation in the parsing call slightly compresses multiple operations. Reading flow: Natural progression from configuration to capability checks and decoding, with explicit buffer cleanup. Minor readability drawbacks include crowded imports, long unwrapped signatures, and similarly named decode overloads requiring attention to their parameter types.