Sample
Scalabrio10
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 43.7Δ 16.3 |
| Scalabrino | 0.184 | 0–1; higher is more readable | 13.6Δ 13.8 |
| Dorn | 0.38 | 0–1; higher is more readable | 43.7Δ 16.3 |
| Mi | 0.291 | 0–1; higher is more readable | 55.8Δ 28.4 |
| LLOC | 19 | Logical lines; fewer is more readable | 28.4Δ 1.0 |
| DeepSeek V4 Pro | 10.67 | 0–20; mean of three runs | 23.4Δ 4.0 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 19.6Δ 7.8 |
| BTTF | 0.05 | 0–1; higher is more readable | 0.5Δ 26.9 |
| Human | 3.22 | 1–5; original rating | 27.4 |
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. | 884.428 | −29.186 |
| 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.52 | −6.78 |
Intercept 8.87 + feature contributions = -17.096 (log-odds).
Score = sigmoid(-17.096) = 0.
| Score | 0.184 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 70.92 | +0.661 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.137 | −0.394 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 25 | −0.153 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 25 | +0.151 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 23.708 | −0.078 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 23 | +0.058 |
Intercept 0.07 + feature contributions = -0.488 (log-odds).
Score = sigmoid(-0.488) = 0.38.
| Score | 0.291 |
|---|
| Score | 19 |
|---|
Run 1
The code has a clear structure with two main branches for different source tables, but suffers from inconsistent indentation that disrupts reading flow. The logic is understandable - handling double-clicks from either a results table or related table - but clarity is undermined by mixed formatting styles. Nesting is acceptable at two levels, though early returns help avoid deeper nesting. Code length is reasonable but the purpose of operations like incrementing 'numJumpToRelated' is ambiguous. Action granularity is mostly one action per line, though the final two lines could be clearer. The biggest issue is the inconsistent spacing and indentation between the if/else blocks, making the code feel disorganized. The null check on 'd' and subsequent setTarget calls are straightforward but could be better structured.
Run 2
The code has basic structure but suffers from readability issues. Indentation is inconsistent (tabs vs spaces) and nesting is moderate. Magic number usage (-1 check) and unclear variable names like 'd' and 'sel' reduce clarity. Multiple actions occur per line in some places (e.g., 'sel = results.elementAt(row)' followed by 'd = ...'). The early return pattern is good, but the final TargetManager setup is confusing - there appear to be two separate setTarget calls when only one may be needed. Logic for relatedTable is incomplete (no diagram assignment), creating ambiguity about the intended behavior. Reading flow is disrupted by the misplaced LOG.debug block and unclear control flow around it.
Run 3
The code has a clear structure with two branches handling different source tables, but it contains several readability issues. The nesting is shallow, which is good, but the early return pattern is inconsistently applied. The method name `myDoubleClick` is poor and doesn't convey intent. Variables like `sel` and `d` are abbreviated. There's a potential bug where both `d` and `sel` targets are set, making the logic ambiguous. The indentation is inconsistent in the second else-if block. Multiple actions occur on single lines (getting row index and incrementing counter). The flow would benefit from extracting the repeated row-checking logic. Overall, the code is functional but lacks clarity.
Run 1
Code Structure: Logically separates handling for the two tables, followed by target updates, but duplicates selection-validation logic. Nesting: Shallow nesting and early returns keep branches manageable. Clarity of intent: The double-click behavior is understandable, though names such as src, sel, and d are terse, and the purpose of setting the target twice is not immediately obvious. Code length: Compact overall, with minor duplication rather than unnecessary verbosity. Action granularity: Each statement performs a single main action, making operations easy to follow. Reading flow: Selection, optional diagram targeting, and final targeting form a natural sequence, but inconsistent indentation interrupts scanning. For an unrecognized source, the final call receives null, leaving the intended behavior unclear.
Run 2
Code Structure: The method is logically organized into source-specific selection handling followed by target updates, though row-selection logic is duplicated. Nesting: Shallow nesting and early returns keep control flow manageable. Clarity of intent: Table selection and navigation are reasonably clear, but names such as myDoubleClick, sel, and d are vague; unsupported sources also lead to setting a null target. Code length: The method is compact, with only minor repetition. Action granularity: Each statement performs one main action, making individual steps easy to follow. Reading flow: Selection precedes navigation naturally, but inconsistent indentation, abbreviated names, and the implicit relationship between diagram and selected-object target updates slightly interrupt readability.
Run 3
Code Structure: Logically separates handling for the two tables, then performs target updates, though selection handling is duplicated. Nesting: Shallow nesting and early returns keep control flow manageable. Clarity of intent: Table names and target-setting calls communicate the general purpose, but myDoubleClick, sel, and d are vague; the reason for setting two targets is unclear. Code length: Short and mostly concise, with minor repetition. Action granularity: Each statement performs one primary action, making individual steps easy to follow. Reading flow: Selection lookup naturally precedes navigation, but inconsistent indentation interrupts scanning. An unrecognized source falls through to setTarget(null), leaving that behavior ambiguous.