Sample

Scalabrio86

Human rating uses the original dataset scale.

DatasetScalabrino
Human4
Lines13

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.4930–1; higher is more readable
91.5Δ 18.1
Scalabrino0.9560–1; higher is more readable
99.5Δ 26.1
Dorn0.8180–1; higher is more readable
94.0Δ 20.6
Mi0.2040–1; higher is more readable
49.2Δ 24.1
LLOC9Logical lines; fewer is more readable
72.6Δ 0.8
DeepSeek V4 Pro130–20; mean of three runs
36.4Δ 36.9
GPT-6.1 Sol170–20; mean of three runs
58.5Δ 14.8
BTTF0.6630–1; higher is more readable
86.4Δ 13.1
Human41–5; original rating
73.4

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.956

Feature contributions

FeatureValueContribution
(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.

Score0.204
Score9
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.