Sample
int-9ead56ffff6d-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.643 | 0–1; higher is more readable |
| Dorn | 0.046 | 0–1; higher is more readable |
| Mi | 0 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.425 | 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. | 4066.04 | −134.179 |
| Source linesThe number of non-empty source lines. | 131 | +52.4 |
| 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.875 | −7.312 |
Intercept 8.87 + feature contributions = -80.221 (log-odds).
Score = sigmoid(-80.221) = 0.
| Score | 0.643 |
|---|
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. | 256.992 | −7.22 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 132 | −3.637 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 257 | +3.342 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 82 | +2.099 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 130.86 | +1.419 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.486 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -3.043 (log-odds).
Score = sigmoid(-3.043) = 0.046.
| Score | 0 |
|---|
| Score | 53 |
|---|
Run 1
This code is severely hampered by formatting issues that make it nearly unreadable despite being logically straightforward. Multiple statements are crammed onto single lines, Javadoc comments are interleaved with code rather than placed above methods, and field declarations are run together. These problems violate nearly every readability criterion: action granularity (multiple actions per line), code structure (compressed and chaotic), nesting (if-else chains become hard to track), and reading flow (non-sequential scanning). While the underlying logic is not deeply nested and the method names are clear, the presentation makes it extremely difficult to parse. The code violates standard Java formatting conventions and would require significant reformatting before it could be maintained or reviewed effectively.
Run 2
The code has severe readability issues. The package and import statements are crammed onto single lines, making the header difficult to scan. Critical structural elements like fields, methods, and Javadoc comments are frequently collapsed onto one line, destroying the natural vertical flow. This violates the 'one action per line' principle and makes the code feel tangled. While the core logic (registering endpoints, resolving container factories) is not deeply nested, the inconsistent brace placement and compressed statements within conditional blocks (e.g., in resolveContainerFactory and registerEndpoint) obscure the intent. The 'reading flow' is severely disrupted by the lack of consistent line breaks. Overall, the code requires significant reformatting to meet basic readability standards, despite the underlying structure being conceptually sound.
Run 3
The code suffers from severe formatting issues that significantly impair readability. Multiple statements are crammed onto single lines (e.g., field declarations, setter methods, and Javadoc comments), violating the 'one action per line' principle. The inconsistent placement of comments and braces creates a tangled structure with poor reading flow. While the core logic and class structure are relatively clear, the code length is unnecessarily compressed, making it difficult to scan. The nesting is moderate, and the intent of the registrar is understandable, but the erratic line breaks and merged declarations obscure the logical organization. Proper formatting alone would raise this to a much higher score, as the underlying design is not inherently complex.
Run 1
Code Structure: Responsibilities are logically separated into configuration, registration, factory resolution, and a descriptor class. Nesting: Mostly shallow, with straightforward loops and conditional branches. Clarity of intent: Descriptive names, assertions, and Javadoc clearly explain endpoint registration and factory selection. Code length: Methods are generally concise; documentation adds length but provides useful context. Action granularity: Multiple imports, fields, assignments, and method statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent brace placement, compressed declarations, comments attached to closing braces, and irregular line breaks disrupt scanning. Overall, the underlying design is readable, but poor formatting significantly reduces accessibility.
Run 2
Code Structure: Logically organized into configuration accessors, registration methods, factory resolution, and a small descriptor class, but compressed formatting obscures those boundaries. Nesting: Shallow loops and conditionals are easy to follow; there is no excessive nesting. Clarity of intent: Descriptive names, Javadoc, assertions, and comments clearly explain endpoint registration and factory fallback behavior. Code length: Methods are generally concise, and documentation is useful, though long signatures and exception text increase visual density. Action granularity: Multiple imports, field declarations, assignments, and method statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent brace placement, comments attached to closing braces, and methods beginning on documentation-ending lines interrupt scanning. The underlying design is readable, but inconsistent formatting substantially reduces accessibility.
Run 3
Code Structure: Responsibilities are logically separated into configuration, registration, factory resolution, and a descriptor class, but compressed formatting obscures these boundaries. Nesting: Shallow loops and conditionals keep complexity manageable. Clarity of intent: Descriptive names, assertions, and detailed Javadoc clearly explain endpoint registration and factory fallback behavior. Code length: Methods are generally concise; documentation adds useful context, though long signatures and error messages increase visual density. Action granularity: Multiple imports, fields, assignments, and statements share lines, making individual actions harder to scan. Reading flow: The overall method order is sensible, but inconsistent brace placement, comments attached to closing braces, and uneven line breaks repeatedly interrupt reading. The underlying design is readable, while presentation substantially reduces accessibility.