Sample
Dorn/java/203
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 50.1Δ 15.3 |
| Scalabrino | 0.715 | 0–1; higher is more readable | 78.3Δ 12.8 |
| Dorn | 0.684 | 0–1; higher is more readable | 63.2Δ 2.2 |
| Mi | 0.769 | 0–1; higher is more readable | 95.5Δ 30.1 |
| LLOC | 11 | Logical lines; fewer is more readable | 57.0Δ 8.5 |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs | 40.9Δ 24.5 |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs | 24.4Δ 41.1 |
| BTTF | 0.44 | 0–1; higher is more readable | 31.2Δ 34.3 |
| Human | 3.52 | 1–5; original rating | 65.5 |
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. | 710.262 | −23.439 |
| Source linesThe number of non-empty source lines. | 30 | +12 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.084 | −7.627 |
Intercept 8.87 + feature contributions = -10.195 (log-odds).
Score = sigmoid(-10.195) = 0.
| Score | 0.715 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77 | +0.438 |
| 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. | 76.968 | +0.405 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 28 | +0.231 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 27 | −0.199 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.109 | −0.119 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 31 | −0.061 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 29.731 | +0.006 |
Intercept 0.07 + feature contributions = 0.772 (log-odds).
Score = sigmoid(0.772) = 0.684.
| Score | 0.769 |
|---|
| Score | 11 |
|---|
Run 1
The code is reasonably readable but has notable issues. The structure is logical, with clear package/import declarations and a straightforward test method. Nesting is moderate but the infinite loop with timeout pattern adds unnecessary complexity. Clarity of intent is acceptable—the test appears to wait for an element to appear—but the purpose could be clearer with a named method or comment. Code length is reasonable for the task. Action granularity is good, with one action per line. Reading flow is mostly natural, but the loop logic disrupts comprehension. The empty catch block is a poor practice. Overall, the code functions but lacks elegance and could benefit from helper methods or a WebDriverWait-style approach to improve readability.
Run 2
The code is difficult to read due to poor structure and clarity. The purpose is not immediately evident. There's a nested try-catch inside a for loop that exacerbates the complexity. The for loop has an unconditional condition (no termination), which is confusing. The use of Exception without narrowing it makes it ambiguous, and the empty catch block obscures error handling. The Thread.sleep is a side effect that disrupts natural reading flow. Variable names like 'second' are vague. Multiple actions and logic are intermingled without explanatory comments, and the overall layout does not guide the reader through the test workflow intuitively.
Run 3
The code demonstrates reasonable structure but has notable readability issues. The class and method are well-defined, following standard test conventions with clear naming. The main problem is the polling loop pattern for AJAX element detection, which is inherently awkward: the infinite loop with break condition, manual Thread.sleep, and empty exception handler create a confusing control flow. The nesting is moderate (try-catch inside for loop), and the action granularity is acceptable. However, the polling logic obscures the method's actual intent of viewing a coupon - the first 15 lines are just waiting for an element to appear, which could be extracted into a helper method like 'waitForElement'. The empty catch block is particularly harmful for debugging. The code would benefit from using Selenium's built-in wait mechanisms or at minimum extracting this boilerplate waiting logic into a reusable utility method to improve reading flow and maintainability.
Run 1
Code Structure: The test follows a logical setup-and-wait sequence, but the excerpt starts with a stray comment terminator and lacks closing braces. Nesting: The loop, try block, and conditional create moderate nesting for a simple wait. Clarity of intent: Selenium calls clearly indicate navigation and waiting for a link, but the coupon-related test name does not match the visible actions, and the empty catch obscures failures. Code length: The snippet is short, though a reusable wait helper would make the polling logic more concise. Action granularity: Each statement performs one action, with consistent indentation and spacing. Reading flow: Execution proceeds naturally from opening the page to loading modules and waiting, but the unusual infinite-loop syntax, hard-coded timeout, and silent exception handling make the flow less immediately clear.
Run 2
Code Structure: Setup and polling are logically ordered, but the snippet has an orphaned comment terminator and lacks closing braces. Nesting: The loop contains a try block and conditional, creating moderate nesting for a simple wait. Clarity of intent: Selenium calls clearly show navigation and waiting for a link, but testViewCoupon does not explain how this checks a coupon; the empty catch hides failures. Code length: Short overall, though a reusable explicit-wait helper could replace the verbose polling logic. Action granularity: Most lines perform one action, making individual steps easy to follow. Reading flow: Indentation and spacing support sequential reading, but the unusual infinite-loop syntax, magic timeout value, swallowed exceptions, and incomplete ending interrupt comprehension.
Run 3
Code Structure: Package, imports, class, and test method are logically organized, but the snippet starts with a stray comment terminator and lacks closing braces. Nesting: The polling loop contains a try block and nested conditional, adding moderate depth. Clarity of intent: Opening a page and waiting for a link are understandable, but the coupon-related test name does not clearly match the visible actions; silently swallowed exceptions obscure failures. Code length: Short overall, though the polling boilerplate could be replaced by a descriptive wait helper. Action granularity: Most lines contain a single action, making individual steps easy to follow. Reading flow: Setup, polling, timeout checking, and sleeping follow a reasonable sequence, but the unusual infinite-loop syntax and incomplete ending interrupt readability.