Sample
Scalabrio145
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 73.9Δ 7.8 |
| Scalabrino | 0.442 | 0–1; higher is more readable | 40.7Δ 25.4 |
| Dorn | 0.237 | 0–1; higher is more readable | 28.6Δ 37.4 |
| Mi | 0.198 | 0–1; higher is more readable | 47.7Δ 18.3 |
| LLOC | 10 | Logical lines; fewer is more readable | 68.6Δ 2.5 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 57.8Δ 8.3 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 7.5 |
| BTTF | 0.653 | 0–1; higher is more readable | 83.9Δ 17.8 |
| Human | 3.89 | 1–5; original rating | 66.1 |
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. | 519.545 | −17.145 |
| Source linesThe number of non-empty source lines. | 19 | +7.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.89 | −7.335 |
Intercept 8.87 + feature contributions = -8.01 (log-odds).
Score = sigmoid(-8.01) = 0.
| Score | 0.442 |
|---|
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. | 108.947 | −0.949 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 19 | +0.364 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 17.727 | −0.162 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 19 | −0.08 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.098 | −0.008 |
Intercept 0.07 + feature contributions = -1.172 (log-odds).
Score = sigmoid(-1.172) = 0.237.
| Score | 0.198 |
|---|
| Score | 10 |
|---|
Run 1
The code is structured logically but suffers from readability issues. Nesting is acceptable (try-catch-finally), but the long chained method calls in the try block create dense lines that reduce clarity. The intent is somewhat clear — testing that a JDBCException occurs for a non-existent table — but the preparation and execution steps are buried in a single chain. Action granularity is poor: multiple actions (get coordinator, get preparer, prepare statement, execute) occur within one statement. Variable names are reasonably descriptive, and the assertion message improves clarity. The finally block is appropriately used. Overall, the code is functional but could be improved by extracting the chained calls into intermediate variables or helper methods to flatten the logic and improve readability.
Run 2
The code is generally readable with a clear structure: setup, try-catch-finally, and assertion. The intent is obvious — test that a JDBCException is thrown for a bad query. Nesting is minimal, and the action granularity is reasonable, though the prepareStatement and execute calls are somewhat verbose but acceptable. The reading flow is natural. Minor deductions: the long chained method calls reduce clarity, and variable names like 'caught' and 'ok' are slightly terse. Overall, it is concise and well-organized for a test method.
Run 3
The code is logically structured with a clear setup-action-assert pattern and uses a try-catch-finally block appropriately. Variable names like 'caught' and 'sessionImpl' clarify intent. However, the chained method calls for preparing and executing statements are long and span multiple lines, making the code harder to read. The nesting is minimal, but the try block contains two multi-line chained calls, reducing action granularity and breaking the 'one action per line' principle. The reading flow is natural, but extracting the statement preparation into a separate variable or helper method would improve clarity.
Run 1
Code Structure: Logically organized into setup, execution, exception handling, cleanup, and assertion. Nesting: Shallow try/catch/finally blocks keep complexity low. Clarity of intent: The test name, nonexistent table, expected exception type, and assertion clearly communicate the purpose; naming the exception 'ok' is less descriptive. Code length: Concise overall, though repeated coordinator-access chains add verbosity. Action granularity: Each statement performs a distinct action, with chained calls making the database operations slightly denser. Reading flow: Natural progression and reliable cleanup make the test easy to follow, but long method chains and the boolean flag modestly reduce readability.
Run 2
Code Structure: The test follows a logical setup, execution, exception handling, cleanup, and assertion sequence. Nesting: A single try-catch-finally block keeps nesting shallow. Clarity of intent: The method name, nonexistent table, and assertion clearly communicate the expected exception, although names such as 'ps' and 'ok' are less descriptive. Code length: The code is reasonably concise, but repeated coordinator-access chains add verbosity. Action granularity: Statements generally perform one action each, though fluent access chains combine several navigation steps. Reading flow: Control flow is natural and cleanup is explicit; long chained calls and the boolean exception flag slightly hinder immediate comprehension.
Run 3
Code Structure: The test logically separates setup, execution, exception handling, cleanup, and assertion. Nesting: A single try/catch/finally keeps nesting shallow. Clarity of intent: The method name, nonexistent table, and assertion message clearly convey the expected exception, though 'ok' is an uninformative exception variable name. Code length: The test is concise, but repeated coordinator access adds verbosity. Action granularity: Each statement performs one primary action, although long method chains combine several navigation steps. Reading flow: Execution proceeds naturally from setup to verification, with reliable cleanup in finally; the boolean flag and lengthy chains slightly interrupt readability.