Sample
Scalabrio30
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 59.8Δ 19.8 |
| Scalabrino | 0.683 | 0–1; higher is more readable | 68.3Δ 28.4 |
| Dorn | 0.68 | 0–1; higher is more readable | 77.4Δ 37.4 |
| Mi | 0.134 | 0–1; higher is more readable | 40.2Δ 0.3 |
| LLOC | 11 | Logical lines; fewer is more readable | 63.1Δ 23.1 |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs | 15.6Δ 24.4 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 9.5Δ 30.4 |
| BTTF | 0.642 | 0–1; higher is more readable | 80.4Δ 40.5 |
| Human | 3.44 | 1–5; original rating | 39.9 |
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. | 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.
| Score | 0.683 |
|---|
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.134 |
|---|
| Score | 11 |
|---|
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.