Sample
Schnappinger/junit4/junit.framework.TestResult
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 42.1Δ 17.6 |
| Scalabrino | 0.887 | 0–1; higher is more readable | 84.9Δ 25.2 |
| Dorn | 0.317 | 0–1; higher is more readable | 48.8Δ 10.9 |
| Mi | 0.635 | 0–1; higher is more readable | 70.3Δ 10.6 |
| LLOC | 65 | Logical lines; fewer is more readable | 33.2Δ 26.6 |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs | 83.0Δ 23.3 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 14.0 |
| BTTF | 0.634 | 0–1; higher is more readable | 63.7Δ 4.0 |
| Human | 3.93 | 1–4; original rating | 59.7 |
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. | 3771.767 | −124.468 |
| Source linesThe number of non-empty source lines. | 185 | +74 |
| 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.361 | −6.541 |
Intercept 8.87 + feature contributions = -48.14 (log-odds).
Score = sigmoid(-48.14) = 0.
| Score | 0.887 |
|---|
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. | 181 | −5.372 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 140 | −2.792 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 184.797 | +2.173 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76.339 | +0.427 |
| 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. | 77.968 | +0.363 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.292 |
Intercept 0.07 + feature contributions = -0.768 (log-odds).
Score = sigmoid(-0.768) = 0.317.
| Score | 0.635 |
|---|
| Score | 65 |
|---|
Run 1
The code is well-structured with clear separation of concerns, minimal nesting, and concise methods. Naming conventions (f-prefix for fields) and Javadoc comments clarify intent despite the legacy style. Methods are short and actions are generally one per line. The use of cloneListeners() adds slight complexity but improves thread safety. The main readability drawback is the dated Java style, which may feel verbose to modern developers, and the reliance on external classes like TestFailure and Protectable without context. Overall, the code is highly readable for its domain.
Run 2
The code is highly readable and well-structured. It follows a consistent pattern with clear method names and Javadoc comments that explain intent. The class is logically organized with fields grouped at the top and methods grouped by functionality. Nesting is minimal, with only one level of indentation in loops and conditionals. Each line performs a single logical action, making the code easy to follow. The reading flow is natural, moving from setup methods to execution methods to query methods. The use of descriptive variable names like 'each' in for-each loops and 'count' in startTest improves clarity. The only minor issue is the slight repetition in addError/addFailure methods, but this is acceptable for clarity. Overall, this is an excellent example of clean, maintainable code.
Run 3
The code is highly readable. It has a clear, logical class structure with well-separated fields and methods. Nesting is minimal, mostly limited to single-level loops and try/catch blocks. The intent of each method is self-evident from both its name and its Javadoc comment. The code is concise; methods are short and focused on a single responsibility. Action granularity is excellent, with one logical operation per line (e.g., adding a failure, then notifying listeners). The reading flow is natural, moving from setup to individual operations to final checks. Synchronization is applied cleanly to protect critical sections without obscuring the logic.
Run 1
Code Structure: Well organized into small, focused methods for result collection, listener notification, and test execution, though related methods could be grouped more consistently. Nesting: Shallow throughout; the anonymous Protectable implementation adds only modest complexity. Clarity of intent: Descriptive method names and documentation clearly explain behavior, including the failure/error distinction; legacy f-prefixed fields and the parameter p slightly reduce clarity. Code length: Appropriate overall, with some repetitive documentation and listener-notification logic. Action granularity: Statements generally perform one action per line, making state changes and callbacks easy to follow. Reading flow: Consistent formatting and straightforward control flow support easy reading, although mixed synchronization styles and the anonymous class require extra attention.
Run 2
Code Structure: Responsibilities are separated into small, focused methods, though method ordering could better group execution, listener management, and result queries. Nesting: Mostly flat, with shallow loops and exception handling; the anonymous Protectable implementation adds minor nesting. Clarity of intent: Descriptive method names and documentation clearly explain result collection and failure/error distinctions, although f-prefixed fields and names like p and each are less expressive. Code length: Methods are concise; repetitive getter comments and listener-notification patterns add some verbosity. Action granularity: Statements generally perform one action per line, making state changes and notifications easy to follow. Reading flow: Consistent formatting and straightforward control flow support readability, but execution-related methods are scattered, and mixed synchronization styles require additional attention.
Run 3
Code Structure: Small, focused methods cleanly separate result collection, listener notification, execution, and status queries, though related methods are not always grouped together. Nesting: Mostly flat, with shallow loops, synchronization blocks, and exception handling; the anonymous class adds minor complexity. Clarity of intent: Descriptive method names and documentation clearly explain behavior, including the distinction between failures and errors. Legacy f-prefixed fields and abbreviated variables such as p and e slightly reduce clarity. Code length: Appropriately concise overall, although repetitive comments, listener loops, and the two-step listener copy add modest verbosity. Action granularity: Statements generally perform one action per line, making changes and side effects easy to follow. Reading flow: Consistent formatting and straightforward control flow support easy reading; scattered execution-related methods and synchronization details require some extra attention.