Sample

Scalabrio30

Human rating uses the original dataset scale.

DatasetScalabrino
Human3.44
Lines25

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
59.8Δ 19.8
Scalabrino0.6830–1; higher is more readable
68.3Δ 28.4
Dorn0.680–1; higher is more readable
77.4Δ 37.4
Mi0.1340–1; higher is more readable
40.2Δ 0.3
LLOC11Logical lines; fewer is more readable
63.1Δ 23.1
DeepSeek V4 Pro9.330–20; mean of three runs
15.6Δ 24.4
GPT-6.1 Sol140–20; mean of three runs
9.5Δ 30.4
BTTF0.6420–1; higher is more readable
80.4Δ 40.5
Human3.441–5; original rating
39.9

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.706.592−23.318
Source linesThe number of non-empty source lines.25+10
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.753−7.129

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

Score0.683

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.105+0.89
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.104.96−0.78
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.25+0.151
Indentation frequencyHow rapidly indentation changes from line to line.24+0.093
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.23.877−0.076
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.096+0.007

Intercept 0.07 + feature contributions = 0.753 (log-odds).
Score = sigmoid(0.753) = 0.68.

Score0.134
Score11
Run 1

The code has a clear overall purpose but suffers from deep nesting and uneven action granularity. The three-level nested if blocks under applyNamingStrategy make the logic harder to follow, especially with an empty branch relying on a trailing comment. The long chained method calls on a single line (lines 7-9) reduce readability, while the alternative branch spreads similar normalization logic across multiple assignments. Overall, the structure is acceptable at a high level, but the nesting and mixed granularity hurt the reading flow.

Run 2

The code has a logical structure but suffers from excessive nesting (three levels) and inconsistent formatting. The intent is moderately clear but could be more explicit through early returns or guard clauses. The method is longer than necessary and contains multiple actions per line, especially in the nested setter calls. The reading flow is disrupted by the deep nesting and formatting inconsistencies. The rename logic could be simplified by handling edge cases first (empty columnName, null propertyName) and then applying the naming strategy. The repeated normalizeIdentifierQuoting calls also add complexity. While variable names are descriptive, the overall readability is reduced by the tangled conditional logic and lack of clear separation between validation, transformation, and assignment steps.

Run 3

The code has clarity of intent but suffers from deep nesting and redundant operations, reducing readability. The outer if-else for applyNamingStrategy creates a three-level nesting. The comment 'Do nothing otherwise' is helpful but the empty if block is awkward. The else branch has 'isNotEmpty' doing the inverse of the earlier 'isEmpty' check, which forces mental context switching. Repeated normalizeIdentifierQuoting calls, especially in the else-if, make the logic unnecessarily long and obscure a clearer sequence: normalize once, apply strategy, normalize again. Action granularity is decent, but the complex expressions on single lines reduce readability. Reading flow is moderate, with the naming strategy path feeling more coherent than the non-strategy path. Overall, it is understandable but would benefit from flattening, early returns, and consolidating normalization logic.

Run 1

Code Structure: The naming-strategy and direct-naming paths are logically separated, but repeated normalization calls add clutter. Nesting: Three levels of conditionals and nested method calls make the main path harder to follow; guard clauses could flatten it. Clarity of intent: Descriptive method and parameter names communicate the purpose, though the need to normalize twice around the naming strategy is unexplained. Code length: Reasonably short, but repeated accessor chains and the explicit no-op comment could be simplified. Action granularity: Most statements perform one action; the property-name branch combines conversion, normalization, and assignment in one expression. Reading flow: Consistent formatting helps, but alternating nested conditions, multiline calls, and columnName reassignment interrupt an otherwise logical progression.

Run 2

Code Structure: Logical branches separate naming-strategy behavior from direct naming, but repeated normalization obscures the organization. Nesting: Three conditional levels and nested method calls make the main path harder to follow. Clarity of intent: Descriptive method and variable names communicate the purpose, although the reason for normalizing twice in one branch is unexplained. Code length: Reasonably short, but repeated accessor chains and verbose branching could be simplified. Action granularity: Most statements perform one action; the property-name branch combines conversion, normalization, and assignment in one expression. Reading flow: Consistent formatting supports reading, but deep indentation and asymmetric branches interrupt the flow.

Run 3

Code Structure: Logically organized around whether the naming strategy applies, but repeated normalization logic adds clutter. Nesting: Three conditional levels and nested method calls make the main branch harder to scan; guard clauses could simplify it. Clarity of intent: Descriptive method and variable names communicate the purpose, though the reason for normalizing both before and after the naming strategy is unexplained. Code length: Reasonably short, but repeated accessor chains and verbose formatting increase visual length. Action granularity: Most statements perform one clear transformation; the property-name branch combines several operations in a single expression. Reading flow: The explicit branches and sequential column-name transformations are understandable, but deep indentation and the trailing alternative branch interrupt a smooth top-to-bottom reading.