Sample
Scalabrio102
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.002 | 0–1; higher is more readable | 76.9Δ 42.0 |
| Scalabrino | 0.696 | 0–1; higher is more readable | 70.9Δ 35.9 |
| Dorn | 0.662 | 0–1; higher is more readable | 74.4Δ 39.4 |
| Mi | 0.026 | 0–1; higher is more readable | 13.6Δ 21.4 |
| LLOC | 9 | Logical lines; fewer is more readable | 72.6Δ 37.7 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 57.8Δ 22.9 |
| GPT-6.1 Sol | 17.33 | 0–20; mean of three runs | 71.9Δ 36.9 |
| BTTF | 0.694 | 0–1; higher is more readable | 91.5Δ 56.5 |
| Human | 3.33 | 1–5; original rating | 34.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. | 694.562 | −22.921 |
| Source linesThe number of non-empty source lines. | 37 | +14.8 |
| 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.752 | −7.129 |
Intercept 8.87 + feature contributions = -6.379 (log-odds).
Score = sigmoid(-6.379) = 0.002.
| Score | 0.696 |
|---|
Feature contributions
| Feature | Value | Contribution (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. | 120.973 | −1.459 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 120.973 | +1.147 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.535 |
| 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. | 37 | −0.274 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 26 | +0.162 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 35.852 | +0.091 |
Intercept 0.07 + feature contributions = 0.672 (log-odds).
Score = sigmoid(0.672) = 0.662.
| Score | 0.026 |
|---|
| Score | 9 |
|---|
Run 1
The code has a clear Javadoc and logical structure, but suffers from excessive length, deep variable chains, and multiple actions per line. The method name is descriptive and intent is clear: check for unresolved entity insert actions. However, the else branch contains long variable declarations with chained method calls (e.g., `dependenciesByAction.keySet().iterator().next()`), reducing readability. The nesting is shallow (only one level), which is good, but the reading flow is disrupted by long lines and dense statements. Action granularity is mixed—some lines perform a single action, while others chain multiple method calls. Overall, the code is functional but would benefit from intermediate variables and line breaks to improve clarity and maintainability.
Run 2
The code is generally readable with clear intent, good logical organization, and a natural flow. The if-else structure is flat and easy to follow. The method name clearly describes its purpose, and the Javadoc provides useful context. However, there are some minor readability issues: several deeply chained method calls on single lines make the code slightly harder to scan (e.g., `dependenciesByAction.keySet().iterator().next()`), and variable names like `firstDependentAction` and `nonNullableTransientDependencies` are somewhat verbose. The exception message is long but clear. Overall, the code is well-structured but could benefit from breaking complex expressions into intermediate variables for improved clarity.
Run 3
The code has a clear structure with an early return for the empty case, reducing nesting. The Javadoc is thorough and clarifies intent. However, readability suffers due to extremely long variable names, multiple chained method calls on single lines, and dense exception construction. Several lines contain multiple actions, hurting action granularity. The reading flow is disrupted by lengthy declarations and deeply chained calls that require careful parsing. While logically organized, the method could be improved by extracting intermediate variables and breaking chains into separate lines.
Run 1
Code Structure: Logically organized into an empty-case check and unresolved-dependency handling. Nesting: Only one conditional level; an early return could flatten the main path further. Clarity of intent: Detailed documentation, descriptive names, and an explicit exception make the purpose clear. Code length: Appropriately concise, though long identifiers and chained iterator calls add visual weight. Action granularity: Each statement performs a distinct step, with intermediate variables separating dependency extraction from exception construction. Reading flow: Natural progression from checking state to logging, identifying the offending association, and throwing an informative exception. Minor drawbacks include lengthy lines and repeated iterator().next() chains.
Run 2
Code Structure: Logically organized into an empty-case check and unresolved-dependency handling. Nesting: Only one conditional level, though an early return could flatten the main path. Clarity of intent: Descriptive method and variable names, documentation, and an explicit exception message clearly communicate the purpose. Code length: Appropriately concise, although verbose identifiers and documentation add visual weight. Action granularity: Each statement performs a distinct action; chained iterator calls slightly increase parsing effort. Reading flow: Naturally progresses from checking for dependencies to selecting the first unresolved action, logging, extracting details, and throwing an informative exception. Long chained expressions and wrapped declarations modestly reduce readability.
Run 3
Code Structure: Logically separates the empty case from dependency inspection and exception construction. Nesting: Only one conditional level, though an early return could remove the else block. Clarity of intent: Detailed Javadoc, descriptive names, and an explicit exception message clearly explain the validation purpose. Code length: Appropriately concise overall, but verbose type names and repeated iterator().next() chains add visual weight. Action granularity: Each declaration, logging call, and throw performs a distinct action; multiline formatting keeps exception arguments readable. Reading flow: Proceeds naturally from checking for unresolved actions to selecting a dependency and reporting it. Long expressions and identifiers slightly slow scanning.