Sample
Schnappinger/junit4/org.junit.runner.notification.RunListener
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 1 | 0–1; higher is more readable | 99.3Δ 6.4 |
| Scalabrino | 0.937 | 0–1; higher is more readable | 96.2Δ 3.3 |
| Dorn | 0.602 | 0–1; higher is more readable | 68.0Δ 24.9 |
| Mi | 0.548 | 0–1; higher is more readable | 41.3Δ 51.7 |
| LLOC | 7 | Logical lines; fewer is more readable | 75.9Δ 17.0 |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs | 91.4Δ 1.5 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 19.1 |
| BTTF | 0.777 | 0–1; higher is more readable | 93.4Δ 0.5 |
| Human | 4 | 1–4; original rating | 92.9 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 140 | +56 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 922.465 | −30.441 |
| 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.555 | −6.833 |
Intercept 8.87 + feature contributions = 27.596 (log-odds).
Score = sigmoid(27.596) = 1.
| Score | 0.937 |
|---|
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. | 140 | −3.921 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 139.933 | +1.546 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 50 | +0.992 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.016 | +0.79 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.752 | +0.595 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 87.929 | −0.059 |
Intercept 0.07 + feature contributions = 0.412 (log-odds).
Score = sigmoid(0.412) = 0.602.
| Score | 0.548 |
|---|
| Score | 7 |
|---|
Run 1
The code is highly readable. It is a well-structured JUnit listener class with clear separation between the main class and a nested annotation. Nesting is minimal — only one nested type, and it is appropriate. Intent is very clear: the class provides empty overrideable callback methods for test lifecycle events, and the Javadoc thoroughly explains each method's purpose and threading behavior. Code length is concise for what it does; there is little or no redundancy. Action granularity is excellent — each method body is empty by design, and the annotations on ThreadSafe are each on separate lines, following conventions. Reading flow is natural, moving from run-level events to atomic test events and finally to the ThreadSafe annotation. Minor deductions are for the slightly long Javadoc examples and empty methods reducing signal-to-noise in some contexts, but this is idiomatic for a listener API.
Run 2
The code is highly readable due to its clear structure, flat organization, and comprehensive Javadoc. The class has a logical flow: imports, class Javadoc, empty listener methods, and a nested annotation. Nesting is minimal; only the annotation is nested, which is appropriate. Intent is explicit through descriptive method names and thorough documentation. Code length is appropriate for an API listener class, with each method being concise. Action granularity is excellent, with one action per method. Reading flow is natural, progressing from lifecycle start to end and then to special cases. Minor deductions: the class could be an interface (but empty method bodies are intentional for optional overriding), and there is slight redundancy in Javadoc examples, but overall this is exemplary readable code.
Run 3
The code is highly readable. It has a clear and logical structure, with imports, class-level Javadoc, method stubs, and a nested annotation type all well-organized. Nesting is minimal; the only nesting is the ThreadSafe annotation inside the class, which is appropriate. Intent is explicit through comprehensive Javadoc for each method and the class. The code is concise—each method is an empty stub with no unnecessary logic. Action granularity is clean, with one clear action or declaration per line. Reading flow is natural: imports, class documentation, then methods in a logical lifecycle order, followed by the annotation. Minor deductions are only for slight verbosity in the class-level Javadoc and the presence of many empty methods, but these are consistent with the listener pattern and do not harm readability.
Run 1
Code Structure: Well-organized listener callbacks followed by a related thread-safety annotation. Nesting: Flat methods with only one straightforward nested annotation declaration. Clarity of intent: Descriptive method names and detailed Javadoc explain callback behavior, but the class documentation incorrectly calls the concrete no-op methods abstract and says to annotate the test class rather than the listener class. Code length: Implementation is concise; extensive documentation adds length but mostly provides useful API context. Action granularity: Each declaration and annotation occupies its own line, with no compound actions. Reading flow: Consistent formatting and lifecycle-oriented ordering make scanning easy, although the documentation inaccuracies slightly disrupt understanding.
Run 2
Code Structure: Imports, listener callbacks, and the thread-safety annotation are logically organized with consistent formatting. Nesting: Almost entirely flat, with only the annotation declaration nested inside the class. Clarity of intent: Descriptive method names and detailed Javadoc clearly explain lifecycle events and threading behavior. However, the class documentation incorrectly calls the concrete, empty methods abstract and refers to annotating the test class rather than the listener class. Code length: Implementation is minimal; documentation is lengthy but mostly useful. Action granularity: Declarations and annotations occupy separate lines, with no compressed multi-action statements. Reading flow: Callbacks progress naturally from run-level events to individual test events, followed by concurrency metadata. Minor documentation inaccuracies and an extra blank line slightly reduce readability.
Run 3
Code Structure: Clearly organized imports, lifecycle callbacks, and a nested thread-safety annotation. Nesting: Minimal nesting, with empty callback bodies and no complex control flow. Clarity of intent: Descriptive method names and detailed Javadoc explain usage and event semantics; however, the class documentation incorrectly calls the concrete methods abstract and suggests annotating the test class rather than the listener class. Code length: Implementation is concise, although extensive documentation makes the file longer. Action granularity: Declarations and annotations occupy separate lines, with no bundled operations. Reading flow: Consistent formatting and lifecycle-oriented ordering make scanning natural, with only minor extra whitespace. Overall, readability is excellent, slightly reduced by misleading documentation.