Sample

Schnappinger/junit4/org.junit.runner.notification.RunListener

Human rating uses the original dataset scale.

Human4
Lines140

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett10–1; higher is more readable
99.3Δ 6.4
Scalabrino0.9370–1; higher is more readable
96.2Δ 3.3
Dorn0.6020–1; higher is more readable
68.0Δ 24.9
Mi0.5480–1; higher is more readable
41.3Δ 51.7
LLOC7Logical lines; fewer is more readable
75.9Δ 17.0
DeepSeek V4 Pro180–20; mean of three runs
91.4Δ 1.5
GPT-6.1 Sol180–20; mean of three runs
73.8Δ 19.1
BTTF0.7770–1; higher is more readable
93.4Δ 0.5
Human41–4; original rating
92.9

Views

Source code

package org.junit.runner.notification; import java.lang.annotation.Documented; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import org.junit.runner.Description; import org.junit.runner.Result; /** * Register an instance of this class with {@link RunNotifier} to be notified * of events that occur during a test run. All of the methods in this class * are abstract and have no implementation; override one or more methods to * receive events. * <p> * For example, suppose you have a <code>Cowbell</code> * class that you want to make a noise whenever a test fails. You could write: * <pre> * public class RingingListener extends RunListener { * public void testFailure(Failure failure) { * Cowbell.ring(); * } * } * </pre> * <p> * To invoke your listener, you need to run your tests through <code>JUnitCore</code>. * <pre> * public void main(String... args) { * JUnitCore core= new JUnitCore(); * core.addListener(new RingingListener()); * core.run(MyTestClass.class); * } * </pre> * <p> * If a listener throws an exception for a test event, the other listeners will * have their {@link RunListener#testFailure(Failure)} called with a {@code Description} * of {@link Description#TEST_MECHANISM} to indicate the failure. * <p> * By default, JUnit will synchronize calls to your listener. If your listener * is thread-safe and you want to allow JUnit to call your listener from * multiple threads when tests are run in parallel, you can annotate your * test class with {@link RunListener.ThreadSafe}. * <p> * Listener methods will be called from the same thread as is running * the test, unless otherwise indicated by the method Javadoc * * @see org.junit.runner.JUnitCore * @since 4.0 */ public class RunListener { /** * Called before any tests have been run. This may be called on an * arbitrary thread. * * @param description describes the tests to be run */ public void testRunStarted(Description description) throws Exception { } /** * Called when all tests have finished. This may be called on an * arbitrary thread. * * @param result the summary of the test run, including all the tests that failed */ public void testRunFinished(Result result) throws Exception { } /** * Called when an atomic test is about to be started. * * @param description the description of the test that is about to be run * (generally a class and method name) */ public void testStarted(Description description) throws Exception { } /** * Called when an atomic test has finished, whether the test succeeds or fails. * * @param description the description of the test that just ran */ public void testFinished(Description description) throws Exception { } /** * Called when an atomic test fails, or when a listener throws an exception. * * <p>In the case of a failure of an atomic test, this method will be called * with the same {@code Description} passed to * {@link #testStarted(Description)}, from the same thread that called * {@link #testStarted(Description)}. * * <p>In the case of a listener throwing an exception, this will be called with * a {@code Description} of {@link Description#TEST_MECHANISM}, and may be called * on an arbitrary thread. * * @param failure describes the test that failed and the exception that was thrown */ public void testFailure(Failure failure) throws Exception { } /** * Called when an atomic test flags that it assumes a condition that is * false * * @param failure describes the test that failed and the * {@link org.junit.AssumptionViolatedException} that was thrown */ public void testAssumptionFailure(Failure failure) { } /** * Called when a test will not be run, generally because a test method is annotated * with {@link org.junit.Ignore}. * * @param description describes the test that will not be run */ public void testIgnored(Description description) throws Exception { } /** * Indicates a {@code RunListener} that can have its methods called * concurrently. This implies that the class is thread-safe (i.e. no set of * listener calls can put the listener into an invalid state, even if those * listener calls are being made by multiple threads without * synchronization). * * @since 4.12 */ @Documented @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface ThreadSafe { } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.937

Feature contributions

FeatureValueContribution
(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.

Score0.548
Score7
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.