Sample
Scalabrio22
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 58.8Δ 35.9 |
| Scalabrino | 0.725 | 0–1; higher is more readable | 75.4Δ 19.3 |
| Dorn | 0.468 | 0–1; higher is more readable | 52.8Δ 42.0 |
| Mi | 0.405 | 0–1; higher is more readable | 68.3Δ 26.4 |
| LLOC | 10 | Logical lines; fewer is more readable | 68.6Δ 26.1 |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs | 54.3Δ 40.5 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 36.2 |
| BTTF | 0.626 | 0–1; higher is more readable | 76.4Δ 18.3 |
| Human | 4.56 | 1–5; original rating | 94.7 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
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. | 667.431 | −22.025 |
| Source linesThe number of non-empty source lines. | 22 | +8.8 |
| 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.182 | −7.773 |
Intercept 8.87 + feature contributions = -12.128 (log-odds).
Score = sigmoid(-12.128) = 0.
| Score | 0.725 |
|---|
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. | 127 | −1.714 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 127 | +1.245 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.07 | +0.262 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 22 | +0.257 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 16 | −0.184 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 20.789 | −0.119 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 16 | +0.054 |
Intercept 0.07 + feature contributions = -0.129 (log-odds).
Score = sigmoid(-0.129) = 0.468.
| Score | 0.405 |
|---|
| Score | 10 |
|---|
Run 1
The code is well-structured and readable. It uses a clear switch statement to handle different SQL states, with each case returning a specific constraint extraction. Nesting is minimal (one try block). Intent is obvious from method name and inline comments. The code is concise — each case takes one or two lines. Action granularity is appropriate: one action per case. Reading flow is natural, with cases ordered by SQL state code and helpful comments. Minor deductions: the long template strings make some lines lengthy, and the TODO comment suggests incomplete handling. Overall, this is clean, maintainable code.
Run 2
The code is moderately readable. It uses a clear switch-based structure mapping SQL state codes to constraint extraction templates, with helpful comments. However, several issues reduce readability: inconsistent indentation (the method body is over-indented), multiple return statements inside the switch with single-line case bodies, mixed comment styles (full-line comments vs inline TODO), and logic split between the try block and catch clause. While the extractUsingTemplate calls are concise, the method would benefit from extracting the mapping into a separate constant or helper, better formatting, and consistent comment placement. The reading flow is disrupted by the awkward try-catch wrapping only the Integer.valueOf call rather than the entire extraction logic.
Run 3
The code is highly readable with a clear purpose and logical structure. It uses a flat switch statement instead of nested if-else blocks, making the flow easy to follow. Each case handles one specific SQL state and returns directly, keeping actions concise. Comments label the constraint violations, improving clarity. The try-catch handles NumberFormatException cleanly. Minor deductions: the method relies on positional string templates (use of "\"" inside literals) which slightly reduces readability, and there is no blank line between cases, though this is minor. Overall, the code is well-organized, concise, and maintains a natural reading flow.
Run 1
Code Structure: The method logically groups SQL-state handling in a switch with a clear fallback. Nesting: The try/switch structure is shallow and easy to follow. Clarity of intent: Descriptive method names and violation comments explain the purpose, though numeric SQL-state literals and returning a column name for a not-null violation slightly obscure the constraint-name contract. Code length: Compact and appropriately sized, with minor repetition in extraction calls. Action granularity: Each case places its label and return on one line, making some lines dense, but each performs a single meaningful action. Reading flow: Cases follow a consistent pattern, and default/error paths are straightforward; uneven indentation and tight argument spacing modestly reduce readability.
Run 2
Code Structure: A focused method with a logically organized switch and clear fallback handling. Nesting: The try/switch adds modest depth, but direct returns avoid deeper branching. Clarity of intent: The method name, helper names, and violation comments explain the purpose; numeric SQL-state codes and delimiter strings require some interpretation. Code length: Concise overall, though repeated extraction calls add minor duplication. Action granularity: Each case combines its label and return on one line, slightly reducing scanability, while other statements remain simple. Reading flow: Cases follow a consistent pattern and the exception fallback is easy to follow, but uneven indentation and cramped argument spacing detract from presentation.
Run 3
Code Structure: A well-organized switch groups SQL states and their extraction rules. Nesting: The try/switch nesting is shallow and easy to follow. Clarity of intent: The method name, descriptive helper, and violation comments explain the purpose, though numeric SQL states and message templates require domain knowledge. Code length: Concise, with little unnecessary code; repeated extraction calls are reasonable here. Action granularity: Each case combines its label and return on one line, making longer cases slightly harder to scan. Reading flow: Cases proceed naturally to a default and exception fallback, but inconsistent spacing and long lines reduce polish. Returning null for both unsupported states and parsing failures leaves those outcomes indistinguishable.