Sample

Scalabrio76

Human rating uses the original dataset scale.

DatasetScalabrino
Human4.44
Lines35

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
34.2Δ 57.3
Scalabrino0.8360–1; higher is more readable
87.9Δ 3.5
Dorn0.3530–1; higher is more readable
41.7Δ 49.7
Mi0.7070–1; higher is more readable
92.5Δ 1.0
LLOC28Logical lines; fewer is more readable
7.8Δ 83.7
DeepSeek V4 Pro160–20; mean of three runs
77.4Δ 14.1
GPT-6.1 Sol170–20; mean of three runs
58.5Δ 32.9
BTTF0.6420–1; higher is more readable
79.4Δ 12.1
Human4.441–5; original rating
91.5

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.1161.221−38.32
Source linesThe number of non-empty source lines.35+14
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.595−6.893

Intercept 8.87 + feature contributions = -22.343 (log-odds).
Score = sigmoid(-22.343) = 0.

Score0.836

Feature contributions

FeatureValueContribution
(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.47.971+1.633
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.0−0.804
Indentation frequencyHow rapidly indentation changes from line to line.1−0.703
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.35−0.382
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.126−0.278
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.35−0.203
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.33.735+0.062

Intercept 0.07 + feature contributions = -0.605 (log-odds).
Score = sigmoid(-0.605) = 0.353.

Score0.707
Score28
Run 1

The code is moderately readable. It follows a logical structure: open session, create and save children, flush, create and save parents, commit. However, the purpose of the unusual naming (e.g., 'achild1-1') and the intermixed save order of children is unclear, suggesting perhaps a deliberate test of ordering, but this is not expressed in the code. Nesting is flat, and action granularity is mostly one action per line, which is good. The main weaknesses are ambiguity of intent and a slight lengthiness due to repetitive object creation and saving. The reading flow is natural for a test setup, but naming and lack of comments reduce clarity.

Run 2

The code is generally readable with clear variable names and a logical flow: children are created, saved, flushed, then parents are created, linked, and saved. The structure is flat with no nesting beyond the method itself, and each action is on its own line, aligning with the action granularity criterion. However, readability is slightly hindered by the awkwardly formatted spacing around parentheses (e.g., 'new Child( "achild1-1")') and inconsistent indentation due to the overridden method signature. Additionally, the interleaved saving of children (1-1, 2-1, 1-2, 2-2, 1-3, 2-3) can be confusing; grouping saves by parent or child sequence would improve clarity of intent. Overall, the code is concise and purposeful, but minor formatting issues and the non-sequential save order prevent a higher score.

Run 3

The code is well-structured and readable. It follows a logical sequence: open session, create children, save them, create parents, associate children, save, commit, close. Nesting is flat with no conditional blocks. Intent is clear from meaningful variable names like child_1_1 and p1. Action granularity is mostly one action per line, with occasional two actions (object creation + addChild on separate lines). Reading flow is natural and follows the domain model. Minor deductions: repetitive save calls could be extracted into a loop or helper method, and some lines combine object creation with method calls. The mixed naming with underscores is slightly inconsistent with camelCase conventions, but remains understandable. Overall, this test setup code is highly readable and maintainable.

Run 1

Code Structure: Clearly separates session setup, child creation and persistence, parent creation, and cleanup. Nesting: Entirely flat, making execution easy to follow. Clarity of intent: Test-data preparation is evident, and numbered child names show parent associations; however, abbreviated session and transaction names and unexplained save ordering slightly obscure intent. Code length: Reasonably concise for a small fixture, though child creation and parent assembly are repetitive. Action granularity: Each statement performs one action on its own line. Reading flow: Mostly natural and sequential, aided by blank lines; the interleaved child-save order and explicit flush could benefit from comments explaining their significance.

Run 2

Code Structure: Clearly separates session setup, child creation and persistence, parent associations, and cleanup. Nesting: Flat, with no nested control flow. Clarity of intent: Test-data preparation is apparent, and child names indicate parent groupings, but abbreviated variables s, t, p1, and p2 reduce clarity. The significance of the interleaved save order and explicit flush is unexplained. Code length: Reasonably concise for a small fixture, though child creation and association are repetitive. Action granularity: Each statement performs a single action. Reading flow: Mostly natural and sequential, with blank lines marking phases; the save order differs from declaration order, slightly disrupting flow.

Run 3

Code Structure: Clearly separates session setup, child creation and persistence, parent associations, and cleanup. Nesting: Flat, with no nested control flow. Clarity of intent: The test-data setup is apparent, but abbreviated names such as s, t, p1, and p2 are less descriptive, and the deliberate child naming, interleaved save order, and flush lack explanation. Code length: Reasonably concise for a small fixture, though child creation and association are repetitive. Action granularity: Each statement performs one action on its own line. Reading flow: Mostly natural and sequential, aided by blank lines; the interleaved save order slightly interrupts the grouping of children by parent.