Sample
Scalabrio197
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 52.8Δ 35.9 |
| Scalabrino | 0.712 | 0–1; higher is more readable | 73.4Δ 56.5 |
| Dorn | 0.397 | 0–1; higher is more readable | 45.7Δ 28.9 |
| Mi | 0.014 | 0–1; higher is more readable | 7.5Δ 9.3 |
| LLOC | 14 | Logical lines; fewer is more readable | 49.2Δ 32.4 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 49.2Δ 32.4 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 34.7Δ 17.8 |
| BTTF | 0.646 | 0–1; higher is more readable | 81.9Δ 65.1 |
| Human | 3 | 1–5; original rating | 16.8 |
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. | 977.368 | −32.253 |
| Source linesThe number of non-empty source lines. | 41 | +16.4 |
| 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.553 | −6.829 |
Intercept 8.87 + feature contributions = -13.812 (log-odds).
Score = sigmoid(-13.812) = 0.
| Score | 0.712 |
|---|
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. | 117.976 | −1.332 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 118 | +1.099 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 41 | −0.415 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.319 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 39.739 | +0.146 |
Intercept 0.07 + feature contributions = -0.417 (log-odds).
Score = sigmoid(-0.417) = 0.397.
| Score | 0.014 |
|---|
| Score | 14 |
|---|
Run 1
The code is generally readable with clear intent and logical structure, but suffers from excessive indentation and verbose parameter wrapping that disrupts flow. The method's purpose—resolving entity keys by first handling bidirectional references, then processing fetches—is communicated well through comments and iteration blocks. Nesting is moderate: a two-level loop with if-else conditions, though the deep indentation from line-wrapping makes it appear more nested than it actually is. Action granularity is mostly good, with one primary action per line (method invocations, variable declarations). However, the code is unnecessarily long due to multi-line parameter formatting that could be condensed. The use of instanceof checks with casts is somewhat dated and adds slight complexity. Reading flow is natural: bidirectional references are processed first (as the comment states), then fetches are categorized and handled. The variable names are descriptive, though 'entityReferenceInitializer' is verbose. Overall, the logic is straightforward but could benefit from reduced line-wrapping or extracted helper methods for better readability.
Run 2
The code is moderately readable but has several issues. The method has clear logical organization, separating bidirectional entity reference resolution from fetch processing, which demonstrates good intent. However, it suffers from excessive nesting (three levels in the fetch loop), inconsistent indentation, and variable naming that could be clearer (the repeated 'entityReferenceInitializer' is verbose). The recursive calls are understandable but the pattern of 'resolve then hydrate' is repeated three times, suggesting potential for extraction into a helper method. Some lines contain multiple operations (nested method calls within get()), reducing action granularity. The reading flow is disrupted by irregular indentation and spacing. While the purpose is discernible—resolving entity keys for both bidirectional and unidirectional fetches—the implementation could be more concise. The instanceof checks with casts are idiomatic but add clutter. Overall, the code is functional but would benefit from refactoring to reduce nesting and repetition.
Run 3
The code has a clear logical structure, with bidirectional references resolved first followed by fetch handling. Method names clearly express intent, and one action per line is mostly maintained. However, readability suffers from deep indentation (up to 5 levels), verbose casting with `Class.isInstance()` checks, and repetitive method signatures that bloat line count. The bidirectionnel loop's null safety isn't explicit, while the mixed loop patterns—first a dedicated collection, then a filtered iteration—create slightly disjointed flow. The `else if` chain is acceptable, but extracting the casts or using pattern matching would improve clarity. Overall, the code is understandable but could benefit from flattening nesting and consolidating repetitive resolution logic.
Run 1
Code Structure: Two distinct loops logically separate bidirectional references from ordinary fetches. Nesting: Moderate nesting in the entity-fetch branch adds some reading effort but remains manageable. Clarity of intent: Descriptive names and the opening comment explain the processing order, though the recursive overloads and differing null checks require external context. Code length: Reasonably concise, but lengthy identifiers and heavily wrapped calls make the method visually longer. Action granularity: Each statement performs a distinct action, with resolution and hydration clearly separated. Reading flow: Processing follows a consistent resolve-then-hydrate sequence, although casts, reflective-style type checks, and minor formatting inconsistencies interrupt the flow.
Run 2
Code Structure: Two distinct loops logically separate bidirectional references from regular fetches, though entity-resolution steps are repeated. Nesting: Moderate nesting in the regular-fetch loop adds some reading effort but remains manageable. Clarity of intent: Descriptive names and the opening comment clarify processing order; recursive overloads and domain-specific types require contextual knowledge. Code length: Reasonably concise, although long identifiers and multiline argument lists make it visually lengthy. Action granularity: Each statement performs a distinct operation, with lookup, resolution, and hydration clearly separated. Reading flow: Processing follows a natural sequence, but runtime type checks, casts, and slightly inconsistent formatting introduce minor friction.
Run 3
Code Structure: Two logically organized loops separate bidirectional references from ordinary fetches, though entity-resolution logic is repeated. Nesting: Moderate nesting in the entity-fetch branch adds some reading effort without becoming tangled. Clarity of intent: Descriptive names and the opening comment explain the processing order; overloaded recursive calls require some external context. Code length: Reasonably concise, but verbose identifiers and multiline calls increase visual length. Action granularity: Each statement performs a distinct action, making operations easy to follow. Reading flow: Processing proceeds naturally from reference lookup to key resolution and state hydration, followed by composite-fetch handling. Minor spacing inconsistencies and repeated argument lists slightly reduce readability.