Sample

Buse/2

Human rating uses the original dataset scale.

DatasetBuse
Human3.74
Lines10

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.0360–1; higher is more readable
27.3Δ 42.4
Dorn0.4530–1; higher is more readable
30.3Δ 39.4
Mi0.4140–1; higher is more readable
30.3Δ 39.4
LLOC6Logical lines; fewer is more readable
11.6Δ 58.1
DeepSeek V4 Pro130–20; mean of three runs
38.4Δ 31.3
GPT-6.1 Sol140–20; mean of three runs
24.7Δ 44.9
BTTF0.4330–1; higher is more readable
33.3Δ 36.4
Human3.741–5; original rating
69.7

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.311.138−10.268
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.3.931−5.897
Source linesThe number of non-empty source lines.10+4

Intercept 8.87 + feature contributions = -3.294 (log-odds).
Score = sigmoid(-3.294) = 0.036.

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.66+0.87
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.0−0.804
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.9+0.718
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.148−0.499
Indentation frequencyHow rapidly indentation changes from line to line.8−0.46
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.9.672−0.275
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.10+0.191

Intercept 0.07 + feature contributions = -0.189 (log-odds).
Score = sigmoid(-0.189) = 0.453.

Score0.414
Score6
Run 1

The code is readable due to its flat nesting structure, clear intent, and concise logic. Each line performs a single action, and the progression from checking the list size to accessing sub-items flows naturally. Minor improvements could include early returns to reduce nesting slightly, but overall the code is well-structured and easy to follow.

Run 2

The code is fairly readable with clear intent and a logical sequence of checks. It uses flat nesting with only two levels, and each condition is simple and concise. The variable names are descriptive and actions are granular. The main downside is the repetitive access to the sub-items array, which could be extracted into a variable to improve clarity and avoid potential null pointer issues if getSubItems() returns null. Overall, it is well-structured and easy to follow, but minor refactoring would enhance readability.

Run 3

The code is logically structured but uses nested conditionals that obscure intent and reduce readability. Each check (size == 1, subItems length 0, subItems length 1) is sequential, but the nesting makes the flow harder to follow than a flat guard-clause pattern. Action granularity is acceptable — one action per line mostly — but repeated `menu.getSubItems()` calls add noise and ambiguity. Variable names like `menu` are misleading (it’s actually an ActionMenu, not a menu). There’s no explanatory context: why return null? The snippet is concise but lacks clarity of purpose. Overall, readable but requires effort to understand, with opportunities to flatten and clarify intent.

Run 1

Code Structure: The conditions are logically organized around a single menu and its subitems. Nesting: Three conditional levels add moderate indentation, though the early return simplifies one branch. Clarity of intent: Descriptive names make the checks understandable, but the purpose of returning null and the final action handling are unclear. Code length: The snippet is concise, although repeated getSubItems() calls could be replaced with a local variable. Action granularity: Each statement performs one clear action. Reading flow: The progression from menu count to subitem count is natural, but the incomplete snippet and unclosed blocks prevent assessing the full control flow.

Run 2

Code Structure: The conditional checks are logically organized, but the snippet is incomplete, with unclosed blocks and an unfinished action-handling path. Nesting: Two levels of conditionals are manageable, and the early return avoids additional nesting. Clarity of intent: Names such as actionList, menu, and getSubItems communicate their roles, though the purpose of returning null and retrieving the action is not fully evident. Code length: The snippet is concise, but repeated getSubItems() calls could be replaced with a local variable for easier reading. Action granularity: Each statement performs one clear action. Reading flow: Consistent indentation and blank lines make the sequence easy to follow, although the abrupt ending limits understanding.

Run 3

Code Structure: The visible logic is organized around handling a single menu and checking its subitems, but the snippet is incomplete. Nesting: Two levels of conditional nesting are manageable, and the early return limits further nesting. Clarity of intent: Descriptive names make the checks understandable, though the reason for returning null and the use of the retrieved action are unclear. Code length: Concise overall, but repeated getSubItems() calls could be replaced with a local variable. Action granularity: Each statement performs one primary action. Reading flow: The progression from one menu to zero or one subitem is natural, with helpful spacing; the abrupt ending and missing closing braces prevent a complete reading.