Sample
Schnappinger/junit4/org.junit.internal.runners.MethodRoadie
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 27.8Δ 16.9 |
| Scalabrino | 0.635 | 0–1; higher is more readable | 27.7Δ 16.8 |
| Dorn | 0.153 | 0–1; higher is more readable | 37.6Δ 26.7 |
| Mi | 0.361 | 0–1; higher is more readable | 22.1Δ 11.2 |
| LLOC | 80 | Logical lines; fewer is more readable | 27.7Δ 16.8 |
| DeepSeek V4 Pro | 13.33 | 0–20; mean of three runs | 24.1Δ 13.2 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 14.9 |
| BTTF | 0.453 | 0–1; higher is more readable | 39.6Δ 28.7 |
| Human | 2.23 | 1–4; original rating | 10.9 |
Views
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. | 5954.968 | −196.514 |
| Source linesThe number of non-empty source lines. | 163 | +65.2 |
| 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.319 | −6.479 |
Intercept 8.87 + feature contributions = -128.923 (log-odds).
Score = sigmoid(-128.923) = 0.
| Score | 0.635 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 164 | −4.77 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 156 | +4.659 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 156 | −3.159 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 162.907 | +1.867 |
| 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. | 127.976 | −1.755 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 127.921 | +1.259 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.118 |
Intercept 0.07 + feature contributions = -1.711 (log-odds).
Score = sigmoid(-1.711) = 0.153.
| Score | 0.361 |
|---|
| Score | 80 |
|---|
Run 1
The code has a clear overall structure with separate methods for setup, test execution, timeout handling, and teardown, and it uses early returns effectively (e.g., in `run()` and `runTestMethod()`). However, readability is hampered by several factors: heavy nesting in `runWithTimeout()` (anonymous inner classes inside a runnable), a misleading comment in `runBeforesThenTestThenAfters()` ('test should never throw...' conflicting with the actual catch), multiple actions packed into long conditional blocks in `runTestMethod()`, and the use of deprecated classes/methods without clarity on replacement. Some methods like `runBefores()` and `runAfters()` have static complexity that could be broken down further. The reading flow is logical but not smooth, and intent is sometimes obscured by boilerplate and legacy patterns.
Run 2
The code has a clear overall structure, with methods broken down into logical steps (setup, test, teardown) and consistent naming conventions. However, readability suffers from moderately deep nesting in runWithTimeout and runTestMethod, making the execution flow harder to follow. Intent is mostly clear, but some sections like the nested ExecutorService logic and multi-line exception messages are visually dense. Code length is generally concise, though a few blocks could be simplified. Action granularity is mixed: some long conditional chains and inline logic reduce per-line clarity. The reading flow is generally natural but disrupted by deeply embedded anonymous classes. Deprecation javadoc is present, which helps context. Overall, the code is understandable but would benefit from reducing nesting and extracting complex anonymous logic into named helpers.
Run 3
The code has a clear structure, with methods like run(), runWithTimeout(), and runTestMethod() logically separating responsibilities. Nesting is mostly flat, though runWithTimeout() and runBefores() contain inner classes and try-catch blocks that increase indentation. Intent is mostly clear, but some terms like 'Roadie' and 'fTest' are non-standard and reduce readability for newcomers. Code length is moderate; no method is excessively long. Action granularity is good—most lines perform a single action. Reading flow is generally natural, but the switch between timeout and non-timeout paths, combined with anonymous inner classes, makes it slightly harder to follow. Error handling is thorough but repetitive in places. The deprecated class is well-documented, which aids understanding. Overall, it is maintainable but could benefit from modern Java features (e.g., lambdas) and clearer naming.
Run 1
Code Structure: Responsibilities are logically separated into lifecycle, timeout, invocation, and failure-reporting methods. Nesting: Most methods are shallow, but nested anonymous classes in timeout handling and nested try blocks in runBefores increase complexity. Clarity of intent: Descriptive method names make the test lifecycle clear; legacy f-prefixed fields, an empty catch block, and subtle exception handling reduce transparency. Code length: Generally proportionate to its responsibilities, although anonymous-class boilerplate and lengthy exception-message expressions add bulk. Action granularity: Statements typically perform one action per line, with consistent formatting. Reading flow: run() provides a clear entry point, and setup/test/cleanup ordering is easy to follow. However, execution jumps through Runnable callbacks and exception-based control flow, making timeout behavior and setup failures harder to trace.
Run 2
Code Structure: Responsibilities are separated into focused methods for execution, timeouts, setup, teardown, and failure reporting. Nesting: Mostly manageable, but anonymous classes in runWithTimeout and nested try/catch blocks in runBefores add complexity. Clarity of intent: Descriptive method names make the test lifecycle clear; legacy f-prefixed fields, the unexplained empty FailedBefore catch, and subtle timeout handling reduce clarity. Code length: Reasonably concise overall, though anonymous-class boilerplate and lengthy exception-message expressions increase reading effort. Action granularity: Statements generally perform one action per line, with clear separation between invocation and failure reporting. Reading flow: run presents the lifecycle naturally, and helper methods follow a sensible order, but asynchronous execution and exception-driven control flow require closer tracing.
Run 3
Code Structure: Responsibilities are logically separated into methods for lifecycle notifications, timeout execution, setup, teardown, and failure reporting. Nesting: Mostly moderate, but nested anonymous classes in runWithTimeout and nested try blocks in runBefores increase reading effort. Clarity of intent: Descriptive method names make the test lifecycle clear; legacy f-prefixed fields, the unexplained empty FailedBefore catch, and subtle timeout mechanics reduce clarity. Code length: Reasonably concise overall, although anonymous-class boilerplate and exception-handling branches add bulk. Action granularity: Statements generally perform one action per line, with consistent formatting; a few long expressions impair scanning. Reading flow: run presents a natural high-level sequence, and helper methods support that sequence, but asynchronous execution and exception unwrapping require readers to trace multiple layers.