Sample
Schnappinger/junit4/junit.textui.TestRunner
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 30.4Δ 67.6 |
| Scalabrino | 0.794 | 0–1; higher is more readable | 60.6Δ 37.4 |
| Dorn | 0.099 | 0–1; higher is more readable | 33.0Δ 65.0 |
| Mi | 0.752 | 0–1; higher is more readable | 91.1Δ 6.9 |
| LLOC | 83 | Logical lines; fewer is more readable | 27.4Δ 70.6 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 44.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 42.7 |
| BTTF | 0.499 | 0–1; higher is more readable | 44.6Δ 53.5 |
| Human | 4 | 1–4; original rating | 98.0 |
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. | 5912.661 | −195.118 |
| Source linesThe number of non-empty source lines. | 206 | +82.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.475 | −6.713 |
Intercept 8.87 + feature contributions = -110.561 (log-odds).
Score = sigmoid(-110.561) = 0.
| Score | 0.794 |
|---|
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. | 206 | −6.257 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 165 | +4.97 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 165 | −3.365 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 204.818 | +2.453 |
| 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. | 119.99 | −1.417 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 119.99 | +1.132 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.076 | +0.208 |
Intercept 0.07 + feature contributions = -2.207 (log-odds).
Score = sigmoid(-2.207) = 0.099.
| Score | 0.752 |
|---|
| Score | 83 |
|---|
Run 1
The code is generally well-structured and readable. It has clear class and method separation, uses Javadoc appropriately, and maintains consistent naming conventions. The nesting depth is minimal, mostly limited to an if-else chain in the 'start' method and a try-catch block. Intent is mostly clear, with methods like 'runSingleMethod' and 'doRun' clearly describing their actions. The code is not unnecessarily long for its purpose, although some methods like 'start' could be slightly simplified. Action granularity is good, with one clear action per line in most methods. The reading flow is natural, moving from constructors to public API methods to internal helpers. Points are deducted for the empty exception handler in the 'pause' method, the slightly tangled command-line argument parsing in 'start', and some redundant catch-and-rethrow logic that could be clearer.
Run 2
The code is well-structured and readable. It has a clear class responsibility (a command-line test runner), with concise methods and purposeful Javadoc. The structure is logical: constructors, static helpers, core execution, then CLI parsing. Nesting is flat overall; the deepest logic in 'start' and 'pause' remains at 2-3 levels, which aids comprehension. Intent is clear due to descriptive method names like 'runSingleMethod' and 'createTestResult'. Code length is appropriate — no excessive boilerplate or redundant abstractions. Action granularity is mostly one action per line, particularly in 'doRun' and 'start'. Reading flow is natural, moving from high-level entry points to supporting implementation. Minor deductions: empty overridden methods (testFailed, testStarted, testEnded) add noise, and variable naming like 'fPrinter' uses a legacy prefix. The 'start' method could be split for clarity, but it remains manageable. Overall, this is clean, maintainable code with slight room for modernizing style.
Run 3
The code is generally well-structured and readable. It has logical organization with clear separation of methods, flat nesting, and good documentation via Javadoc comments. Constructors are overloaded cleanly, and methods have single responsibilities. However, a few areas reduce readability: the 'start' method contains a multi-branch argument parsing loop with moderate complexity, and some methods (like 'doRun') mix timing, listener registration, and result printing. Empty overridden methods add clutter without explanation. Action granularity is mostly one-per-line, though some lines combine multiple operations. Overall, readable but with minor opportunities for simplification.
Run 1
Code Structure: Well-organized into constructors, execution helpers, command-line handling, and output configuration, with clear separation of responsibilities. Nesting: Mostly shallow; the argument-parsing loop and conditional chain introduce only moderate complexity. Clarity of intent: Descriptive method names, named exit constants, and documentation explain the runner's purpose. Empty overrides and a silently ignored exception obscure some intent, while names such as r and fPrinter are less expressive. Code length: Most methods are concise, though constructor comments and wrapper methods add some verbosity. Action granularity: Statements generally perform one action per line; args[++i] combines index advancement with argument access, and the inline guard in pause is slightly less readable. Reading flow: Execution proceeds naturally through setup, running, reporting, and optional waiting. The longer start method, inconsistent declaration style, and scattered command-line concerns slightly interrupt otherwise strong readability.
Run 2
Code Structure: Well-separated methods handle construction, execution, argument parsing, and reporting; start combines parsing and dispatch but remains manageable. Nesting: Mostly shallow, with modest nesting in the argument loop and exception handling. Clarity of intent: Descriptive method names, exit constants, and documentation make the purpose clear; legacy names such as fPrinter, aTestRunner, and r, plus unexplained empty callbacks and a swallowed exception, reduce clarity. Code length: Generally concise, though repetitive constructor comments and wrapper methods add some verbosity. Action granularity: Nearly all statements perform one action per line; args[++i] combines index advancement with argument access, and the inline early return slightly compresses control flow. Reading flow: Consistent indentation and a natural progression from setup to execution support easy reading, with minor distractions from inconsistent modifier ordering and extra blank lines.
Run 3
Code Structure: Well-organized constructors, execution helpers, and command-line handling separate responsibilities. Nesting: Generally shallow, although start() combines a loop with a multi-branch conditional and exception handling. Clarity of intent: Descriptive methods, named exit constants, and documentation make the purpose clear; abbreviated names such as r, legacy fPrinter naming, and unexplained empty callbacks/catch blocks reduce clarity. Code length: Most methods are concise, though some comments repeat obvious behavior and argument parsing could be extracted. Action granularity: Mostly one action per line, with minor exceptions such as the inline guard return and incrementing i inside array access. Reading flow: Test execution follows a natural sequence from setup through execution, reporting, and optional pause. Mixing argument parsing and execution in start(), along with inconsistent declaration conventions, slightly interrupts an otherwise straightforward flow.