Sample
Scalabrio86
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.493 | 0–1; higher is more readable | 91.5Δ 18.1 |
| Scalabrino | 0.956 | 0–1; higher is more readable | 99.5Δ 26.1 |
| Dorn | 0.818 | 0–1; higher is more readable | 94.0Δ 20.6 |
| Mi | 0.204 | 0–1; higher is more readable | 49.2Δ 24.1 |
| LLOC | 9 | Logical lines; fewer is more readable | 72.6Δ 0.8 |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs | 36.4Δ 36.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 14.8 |
| BTTF | 0.663 | 0–1; higher is more readable | 86.4Δ 13.1 |
| Human | 4 | 1–5; original rating | 73.4 |
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. | 216.096 | −7.131 |
| 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.644 | −6.966 |
| Source linesThe number of non-empty source lines. | 13 | +5.2 |
Intercept 8.87 + feature contributions = -0.027 (log-odds).
Score = sigmoid(-0.027) = 0.493.
| Score | 0.956 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 13 | +0.576 |
| 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. | 73.846 | +0.537 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.487 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 74 | +0.39 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 11.067 | −0.255 |
Intercept 0.07 + feature contributions = 1.5 (log-odds).
Score = sigmoid(1.5) = 0.818.
| Score | 0.204 |
|---|
| Score | 9 |
|---|
Run 1
The code has a clear purpose—testing HQL parsing of column/alias names that resemble keywords—but its readability is weakened by repetitive and cryptic test strings. Structure is logically sequential, and nesting is flat. However, the intent is not obvious without domain knowledge, and several lines perform multiple conceptual actions (constructing complex query strings and parsing them). The inline comments help, but the lack of test case separation or helper methods hurts clarity. Overall, it is understandable but not polished.
Run 2
The test method has a clear purpose: testing keyword-as-identifier parsing. Each parse call is on its own line, which is good for action granularity. The comments add some context ('Super evil badness', 'Okay, now this is getting silly') but are informal and do not explain what each case tests. The structure is flat, which helps readability, but there is no setup or assertion, making the test's success criteria ambiguous. The method name is descriptive, but the comments and lack of organization (e.g., grouping by clause type) make the flow feel somewhat disorganized. The code is concise, but the unexplained commented-out line adds confusion. Overall, it is readable but could benefit from clearer comments and structured grouping of test cases.
Run 3
The code has a clear purpose (testing keyword-as-identifier edge cases) and is relatively flat. However, readability suffers from several issues: multiple parse calls per line, commented-out code without explanation, inconsistent formatting, and a lack of descriptive comments for each test case. The method name is clear, but the inline comments ('Super evil badness...', 'Okay, now this is getting silly.') add conversational noise rather than clarity. The action granularity is poor—multiple parse statements are grouped on single lines without spacing, making the test cases harder to individually identify and debug. Reading flow is disjointed; grouping related cases or using a table-driven approach with descriptive names would improve understandability. The commented-out parse call adds ambiguity about whether it's intentional or obsolete. Overall, the code is functional but not polished for readability.
Run 1
Code Structure: A single focused test organizes related parsing cases logically, though grouping cases by keyword usage would improve organization. Nesting: The method is entirely flat and easy to scan. Clarity of intent: The descriptive method name and query examples clearly communicate testing keywords as identifiers; informal comments and a commented-out case add minor ambiguity. Code length: Concise, with little unnecessary content beyond the disabled parse call. Action granularity: Each active line performs one parsing action, although the annotation and method declaration share a line. Reading flow: Sequential examples are straightforward to follow, but their progression is not explicitly explained. Overall, the code is highly readable with minor formatting and documentation weaknesses.
Run 2
Code Structure: A single focused test method logically groups related parsing cases, though cases are not categorized. Nesting: The body is completely flat and easy to scan. Clarity of intent: The descriptive method name clearly identifies keyword-as-identifier testing; informal comments and a commented-out case add minor ambiguity. Code length: Short and appropriately concise for the cases covered. Action granularity: Each active line performs one parse operation, although the annotation and declaration share a line. Reading flow: Repeated parse calls create a predictable flow, but inconsistent spacing, informal commentary, and the disabled case slightly interrupt it.
Run 3
Code Structure: A single focused test method groups related keyword-as-identifier cases logically, although individual scenarios are not labeled. Nesting: The body is completely flat, making it easy to scan. Clarity of intent: The descriptive method name and query examples communicate the purpose clearly; informal comments and a commented-out test introduce minor ambiguity. Code length: Short and appropriately concise for the number of cases. Action granularity: Each active line performs one parse operation, though the annotation and method declaration share a line. Reading flow: The sequential cases are straightforward to follow, but more purposeful grouping and removal or explanation of the disabled case would improve readability.