Sample
int-d79a0daf5581-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.437 | 0–1; higher is more readable |
| Dorn | 0.027 | 0–1; higher is more readable |
| Mi | 0 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.142 | 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. | 4610.646 | −152.151 |
| Source linesThe number of non-empty source lines. | 83 | +33.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.958 | −7.437 |
Intercept 8.87 + feature contributions = -117.518 (log-odds).
Score = sigmoid(-117.518) = 0.
| Score | 0.437 |
|---|
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. | 286 | −8.449 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 285.976 | +3.81 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 84 | −1.938 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 70 | +1.684 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 82.808 | +0.748 |
| 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.089 | +0.074 |
Intercept 0.07 + feature contributions = -3.603 (log-odds).
Score = sigmoid(-3.603) = 0.027.
| Score | 0 |
|---|
| Score | 50 |
|---|
Run 1
The code is severely unreadable. Multiple methods and class declarations are packed onto single lines, violating standard formatting and making the structure hard to follow. The nesting level is moderate, but the lack of line breaks creates an impression of deep, tangled nesting. Intent is sometimes clear from the method names and Javadoc, but the compressed layout obscures it. The code is not concise; it is actually verbose in logic but presented in a compressed, unreadable way. Action granularity is broken—multiple statements per line make it impossible to scan. Reading flow is completely disorganized, as the eye cannot easily separate method boundaries or follow control flow. While the underlying logic is straightforward, the formatting alone drops the score from excellent to very poor.
Run 2
The code suffers from severe formatting issues that drastically reduce readability. Multiple statements and method declarations are crammed onto single lines, making it difficult to distinguish logical blocks and individual actions. Nesting is not overly deep, but the lack of line breaks creates a tangled appearance. Intent is partially clear from comments and naming, but the dense layout obscures the flow. Code length is reasonable but not helped by the formatting. Action granularity violates the 'one action per line' principle extensively. The reading flow is severely disrupted by the inconsistent line breaks and mashed-together methods, making it hard to scan and understand. The code could be readable with normal formatting, but as presented it is very hard to parse.
Run 3
The code is structurally logical but severely compromised by formatting. Multiple methods and statements are crammed onto single lines, making it difficult to parse. While the core logic and intent are understandable, the reading flow is poor due to inconsistent line breaks and indentation. Nesting is relatively shallow, and action granularity suffers from multiple actions being placed on one line. The code would be significantly more readable with standard formatting practices applied consistently.
Run 1
Code Structure: The converter has a logical organization with focused helper methods and an entry class, but compressed method boundaries obscure that structure. Nesting: Mostly shallow, with guard clauses and simple loops; nesting is not a major obstacle. Clarity of intent: Descriptive names and class documentation clearly explain map conversion, although the deferred copying logic requires some attention. Code length: Reasonably concise for the functionality, with little unnecessary logic. Action granularity: Multiple imports, declarations, assignments, and method definitions share lines, making individual actions difficult to scan. Reading flow: Inconsistent indentation, crowded braces, long lines, and annotations attached to preceding methods interrupt natural reading. Overall, the underlying design is readable, but poor formatting substantially reduces accessibility.
Run 2
Code Structure: Sensible separation into conversion methods, helpers, and an entry class, but compressed formatting obscures boundaries. Nesting: Mostly shallow, with early returns and straightforward loops. Clarity of intent: Descriptive names and documentation clearly communicate map conversion and conditional copying. Code length: Reasonably concise for its functionality, although entry buffering adds some reading overhead. Action granularity: Frequently poor; imports, declarations, assignments, method boundaries, and returns share lines. Reading flow: Inconsistent brace placement, crowded annotations, and merged statements interrupt otherwise logical execution flow. The underlying design is readable, but presentation substantially reduces scanability.
Run 3
Code Structure: Responsibilities are logically separated into conversion, compatibility checks, and an entry helper, but compressed formatting obscures method boundaries. Nesting: Mostly shallow, with early returns and straightforward loops. Clarity of intent: Descriptive names and class documentation clearly explain map conversion and copy avoidance. Code length: Reasonably concise for its functionality, though the entry helper adds some boilerplate. Action granularity: Multiple imports, declarations, assignments, and method boundaries share lines, making individual operations harder to distinguish. Reading flow: Inconsistent line breaks, crowded annotations, and misplaced closing braces interrupt an otherwise natural sequence of validation, conversion, and map construction.