Sample
Schnappinger/junit4/org.junit.runner.notification.RunNotifier
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 35.8Δ 13.1 |
| Scalabrino | 0.795 | 0–1; higher is more readable | 61.3Δ 12.5 |
| Dorn | 0.163 | 0–1; higher is more readable | 38.6Δ 10.2 |
| Mi | 0.559 | 0–1; higher is more readable | 44.6Δ 4.3 |
| LLOC | 67 | Logical lines; fewer is more readable | 31.7Δ 17.2 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 4.3 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 6.4 |
| BTTF | 0.648 | 0–1; higher is more readable | 67.3Δ 18.5 |
| Human | 3.9 | 1–4; original rating | 48.8 |
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. | 4920.47 | −162.376 |
| Source linesThe number of non-empty source lines. | 214 | +85.6 |
| 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.372 | −6.557 |
Intercept 8.87 + feature contributions = -74.463 (log-odds).
Score = sigmoid(-74.463) = 0.
| Score | 0.795 |
|---|
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. | 215 | −6.576 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 163 | +4.901 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 163 | −3.32 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 213.784 | +2.578 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 92.898 | +0.694 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.416 |
| 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. | 95.944 | −0.399 |
Intercept 0.07 + feature contributions = -1.635 (log-odds).
Score = sigmoid(-1.635) = 0.163.
| Score | 0.559 |
|---|
| Score | 67 |
|---|
Run 1
The code is generally well-structured and readable. It uses clear class and method names, and Javadocs explain intent. The SafeNotifier inner class centralizes listener notification logic, reducing duplication. However, readability is hampered by some issues: the wrapIfNotThreadSafe method uses a ternary on separate lines, which can be slightly hard to scan. The fireTestFailures method has a non-standard parameter indentation. Deep nesting is mild, but the SafeNotifier.run() method contains a try/catch and loop, which is acceptable. The code is concise overall. The use of an abstract inner class with anonymous subclasses for each event adds some overhead to reading flow, as each fireTest* method follows a similar pattern. The unusual 'f' prefix for field names (e.g., fListeners, fPleaseStop) is a holdover from older Java style and may confuse modern readers.
Run 2
The code is generally well-structured and readable. It uses a clear class-level organization with a helper inner class (SafeNotifier) to centralize listener notification and error handling, which reduces duplication. Nesting is moderate and largely unavoidable due to anonymous inner classes for event-specific notifications. Intent is mostly clear through descriptive method names and Javadoc, though some methods rely on comments like 'Do not invoke' which could be more explicit. Length is reasonable, but the repeated anonymous SafeNotifier subclasses add verbosity. Action granularity is good—most methods perform one logical action per statement. Reading flow is natural, with public API methods followed by private helpers. Minor issues include the use of Hungarian notation (fListeners, fPleaseStop), a long method signature split over lines, and the SafeNotifier's run() method handling multiple responsibilities (collecting listeners, catching exceptions, firing failures) in one block.
Run 3
The code is well-structured with clear separation of concerns. The RunNotifier class manages listeners efficiently using CopyOnWriteArrayList for thread safety. The SafeNotifier inner class elegantly handles exception isolation between listeners, preventing one faulty listener from breaking the notification chain. Method names are descriptive and follow clear intent. However, the repetitive anonymous inner class pattern for each fire method adds verbosity, though it maintains consistency. The nesting is shallow with only one level in most methods. The field naming convention (fListeners, fPleaseStop) is somewhat dated and reduces modern readability. Each line performs a single action, aiding comprehension. The Javadoc comments are helpful but could be more concise. Overall, the code is highly readable with minor stylistic concerns around the Hungarian notation and repetitive patterns that could be refactored using lambda expressions in modern Java.
Run 1
Code Structure: Small, focused methods and the shared SafeNotifier abstraction organize listener management and event dispatch logically. Nesting: Mostly shallow, though anonymous classes and the failure-dispatch loop introduce moderate nesting. Clarity of intent: Descriptive method names and useful Javadoc make the purpose clear; prefixed field names and recursive failure reporting require closer attention. Code length: Individual methods are concise, but repeated anonymous-class boilerplate makes the class longer than its core behavior warrants. Action granularity: Statements generally perform one action per line, with clean separation of validation, notification, and failure collection. Reading flow: Consistent formatting and repeated dispatch patterns make navigation predictable, although tracing error handling between SafeNotifier.run and fireTestFailures interrupts the otherwise natural flow.
Run 2
Code Structure: Responsibilities are logically separated into listener management, safe dispatch, and event methods; SafeNotifier centralizes exception handling. Nesting: Mostly shallow, although anonymous classes and the failure-dispatch loop introduce moderate nesting. Clarity of intent: Descriptive method names and useful Javadoc clearly communicate behavior; prefixed fields and generic names such as 'each' are minor weaknesses. Code length: Methods are short, but repeated anonymous-class boilerplate makes the class longer than its functionality warrants. Action granularity: Statements generally perform one action per line, with clear separation of validation and execution. Reading flow: Consistent formatting and repeated dispatch patterns make navigation predictable, though tracing recursive failure reporting between SafeNotifier.run and fireTestFailures requires extra attention.
Run 3
Code Structure: Well-organized methods and a shared SafeNotifier abstraction centralize notification and exception handling. Nesting: Generally shallow, although anonymous classes and the failure-notification loop introduce moderate nesting. Clarity of intent: Descriptive method names and useful Javadoc clearly explain the API; prefixed fields and generic names such as 'each' are minor weaknesses. Code length: Individual methods are concise, but repeated anonymous-class boilerplate makes the class longer than necessary. Action granularity: Statements generally perform one action per line, with straightforward validation and dispatch. Reading flow: Consistent formatting and repeated notification patterns make the code easy to follow. However, failure handling cycles between SafeNotifier.run and fireTestFailures, requiring extra effort to understand recursive propagation and termination.