Sample

Schnappinger/junit4/org.junit.runner.Description

Human rating uses the original dataset scale.

Human4
Lines311

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
31.8Δ 62.0
Scalabrino0.8030–1; higher is more readable
63.0Δ 30.7
Dorn0.0250–1; higher is more readable
24.1Δ 69.6
Mi0.2690–1; higher is more readable
18.2Δ 75.6
LLOC89Logical lines; fewer is more readable
26.9Δ 66.8
DeepSeek V4 Pro170–20; mean of three runs
66.8Δ 26.9
GPT-6.1 Sol170–20; mean of three runs
55.3Δ 38.4
BTTF0.5460–1; higher is more readable
49.2Δ 44.6
Human41–4; original rating
93.7

Views

Source code

package org.junit.runner; import java.io.Serializable; import java.lang.annotation.Annotation; import java.util.ArrayList; import java.util.Arrays; import java.util.Collection; import java.util.concurrent.ConcurrentLinkedQueue; import java.util.regex.Matcher; import java.util.regex.Pattern; /** * A <code>Description</code> describes a test which is to be run or has been run. <code>Descriptions</code> * can be atomic (a single test) or compound (containing children tests). <code>Descriptions</code> are used * to provide feedback about the tests that are about to run (for example, the tree view * visible in many IDEs) or tests that have been run (for example, the failures view). * <p> * <code>Descriptions</code> are implemented as a single class rather than a Composite because * they are entirely informational. They contain no logic aside from counting their tests. * <p> * In the past, we used the raw {@link junit.framework.TestCase}s and {@link junit.framework.TestSuite}s * to display the tree of tests. This was no longer viable in JUnit 4 because atomic tests no longer have * a superclass below {@link Object}. We needed a way to pass a class and name together. Description * emerged from this. * * @see org.junit.runner.Request * @see org.junit.runner.Runner * @since 4.0 */ public class Description implements Serializable { private static final long serialVersionUID = 1L; private static final Pattern METHOD_AND_CLASS_NAME_PATTERN = Pattern .compile("(.*)\\((.*)\\)"); /** * Create a <code>Description</code> named <code>name</code>. * Generally, you will add children to this <code>Description</code>. * * @param name the name of the <code>Description</code> * @param annotations meta-data about the test, for downstream interpreters * @return a <code>Description</code> named <code>name</code> */ public static Description createSuiteDescription(String name, Annotation... annotations) { return new Description(null, name, annotations); } /** * Create a <code>Description</code> named <code>name</code>. * Generally, you will add children to this <code>Description</code>. * * @param name the name of the <code>Description</code> * @param uniqueId an arbitrary object used to define uniqueness (in {@link #equals(Object)} * @param annotations meta-data about the test, for downstream interpreters * @return a <code>Description</code> named <code>name</code> */ public static Description createSuiteDescription(String name, Serializable uniqueId, Annotation... annotations) { return new Description(null, name, uniqueId, annotations); } /** * Create a <code>Description</code> of a single test named <code>name</code> in the 'class' named * <code>className</code>. Generally, this will be a leaf <code>Description</code>. This method is a better choice * than {@link #createTestDescription(Class, String, Annotation...)} for test runners whose test cases are not * defined in an actual Java <code>Class</code>. * * @param className the class name of the test * @param name the name of the test (a method name for test annotated with {@link org.junit.Test}) * @param annotations meta-data about the test, for downstream interpreters * @return a <code>Description</code> named <code>name</code> */ public static Description createTestDescription(String className, String name, Annotation... annotations) { return new Description(null, formatDisplayName(name, className), annotations); } /** * Create a <code>Description</code> of a single test named <code>name</code> in the class <code>clazz</code>. * Generally, this will be a leaf <code>Description</code>. * * @param clazz the class of the test * @param name the name of the test (a method name for test annotated with {@link org.junit.Test}) * @param annotations meta-data about the test, for downstream interpreters * @return a <code>Description</code> named <code>name</code> */ public static Description createTestDescription(Class<?> clazz, String name, Annotation... annotations) { return new Description(clazz, formatDisplayName(name, clazz.getName()), annotations); } /** * Create a <code>Description</code> of a single test named <code>name</code> in the class <code>clazz</code>. * Generally, this will be a leaf <code>Description</code>. * (This remains for binary compatibility with clients of JUnit 4.3) * * @param clazz the class of the test * @param name the name of the test (a method name for test annotated with {@link org.junit.Test}) * @return a <code>Description</code> named <code>name</code> */ public static Description createTestDescription(Class<?> clazz, String name) { return new Description(clazz, formatDisplayName(name, clazz.getName())); } /** * Create a <code>Description</code> of a single test named <code>name</code> in the class <code>clazz</code>. * Generally, this will be a leaf <code>Description</code>. * * @param name the name of the test (a method name for test annotated with {@link org.junit.Test}) * @return a <code>Description</code> named <code>name</code> */ public static Description createTestDescription(String className, String name, Serializable uniqueId) { return new Description(null, formatDisplayName(name, className), uniqueId); } private static String formatDisplayName(String name, String className) { return String.format("%s(%s)", name, className); } /** * Create a <code>Description</code> named after <code>testClass</code> * * @param testClass A {@link Class} containing tests * @return a <code>Description</code> of <code>testClass</code> */ public static Description createSuiteDescription(Class<?> testClass) { return new Description(testClass, testClass.getName(), testClass.getAnnotations()); } /** * Describes a Runner which runs no tests */ public static final Description EMPTY = new Description(null, "No Tests"); /** * Describes a step in the test-running mechanism that goes so wrong no * other description can be used (for example, an exception thrown from a Runner's * constructor */ public static final Description TEST_MECHANISM = new Description(null, "Test mechanism"); private final Collection<Description> fChildren = new ConcurrentLinkedQueue<Description>(); private final String fDisplayName; private final Serializable fUniqueId; private final Annotation[] fAnnotations; private volatile /* write-once */ Class<?> fTestClass; private Description(Class<?> clazz, String displayName, Annotation... annotations) { this(clazz, displayName, displayName, annotations); } private Description(Class<?> clazz, String displayName, Serializable uniqueId, Annotation... annotations) { if ((displayName == null) || (displayName.length() == 0)) { throw new IllegalArgumentException( "The display name must not be empty."); } if ((uniqueId == null)) { throw new IllegalArgumentException( "The unique id must not be null."); } fTestClass = clazz; fDisplayName = displayName; fUniqueId = uniqueId; fAnnotations = annotations; } /** * @return a user-understandable label */ public String getDisplayName() { return fDisplayName; } /** * Add <code>Description</code> as a child of the receiver. * * @param description the soon-to-be child. */ public void addChild(Description description) { fChildren.add(description); } /** * Gets the copy of the children of this {@code Description}. * Returns an empty list if there are no children. */ public ArrayList<Description> getChildren() { return new ArrayList<Description>(fChildren); } /** * @return <code>true</code> if the receiver is a suite */ public boolean isSuite() { return !isTest(); } /** * @return <code>true</code> if the receiver is an atomic test */ public boolean isTest() { return fChildren.isEmpty(); } /** * @return the total number of atomic tests in the receiver */ public int testCount() { if (isTest()) { return 1; } int result = 0; for (Description child : fChildren) { result += child.testCount(); } return result; } @Override public int hashCode() { return fUniqueId.hashCode(); } @Override public boolean equals(Object obj) { if (!(obj instanceof Description)) { return false; } Description d = (Description) obj; return fUniqueId.equals(d.fUniqueId); } @Override public String toString() { return getDisplayName(); } /** * @return true if this is a description of a Runner that runs no tests */ public boolean isEmpty() { return equals(EMPTY); } /** * @return a copy of this description, with no children (on the assumption that some of the * children will be added back) */ public Description childlessCopy() { return new Description(fTestClass, fDisplayName, fAnnotations); } /** * @return the annotation of type annotationType that is attached to this description node, * or null if none exists */ public <T extends Annotation> T getAnnotation(Class<T> annotationType) { for (Annotation each : fAnnotations) { if (each.annotationType().equals(annotationType)) { return annotationType.cast(each); } } return null; } /** * @return all of the annotations attached to this description node */ public Collection<Annotation> getAnnotations() { return Arrays.asList(fAnnotations); } /** * @return If this describes a method invocation, * the class of the test instance. */ public Class<?> getTestClass() { if (fTestClass != null) { return fTestClass; } String name = getClassName(); if (name == null) { return null; } try { fTestClass = Class.forName(name, false, getClass().getClassLoader()); return fTestClass; } catch (ClassNotFoundException e) { return null; } } /** * @return If this describes a method invocation, * the name of the class of the test instance */ public String getClassName() { return fTestClass != null ? fTestClass.getName() : methodAndClassNamePatternGroupOrDefault(2, toString()); } /** * @return If this describes a method invocation, * the name of the method (or null if not) */ public String getMethodName() { return methodAndClassNamePatternGroupOrDefault(1, null); } private String methodAndClassNamePatternGroupOrDefault(int group, String defaultString) { Matcher matcher = METHOD_AND_CLASS_NAME_PATTERN.matcher(toString()); return matcher.matches() ? matcher.group(group) : defaultString; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.6994.788−230.828
Source linesThe number of non-empty source lines.311+124.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.613−6.92

Intercept 8.87 + feature contributions = -104.478 (log-odds).
Score = sigmoid(-104.478) = 0.

Score0.803

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.311−9.975
Indentation frequencyHow rapidly indentation changes from line to line.202+6.25
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.201−4.191
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.309.882+3.922
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.117.971−1.332
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.117.942+1.098
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.045+0.502

Intercept 0.07 + feature contributions = -3.656 (log-odds).
Score = sigmoid(-3.656) = 0.025.

Score0.269
Score89
Run 1

The code is generally well-structured and readable. It uses clear naming conventions, logical grouping of static factory methods, and concise helper methods like formatDisplayName and methodAndClassNamePatternGroupOrDefault. Nesting is minimal, and most methods are short and focused with a single responsibility. The Javadoc comments are thorough and explain intent well. However, readability is slightly reduced by the use of legacy 'f' field prefixes (e.g., fChildren, fDisplayName), inconsistent parameter ordering across factory methods, and some redundancy in overloaded createTestDescription and createSuiteDescription methods. The equals method lacks an instanceof symmetry check for subclasses but is acceptable. Overall, the code is easy to follow and maintain, but minor style inconsistencies and verbose factory overloads prevent a higher score.

Run 2

The code is highly readable and well-structured. It has a clear, logical organization with all factory methods grouped together, followed by constructors, then public methods, and finally private helpers. Nesting is minimal — the deepest logic appears in getTestClass and testCount, but remains shallow and easy to follow. Intent is clearly expressed through descriptive method names and comprehensive Javadoc, reflecting the expectations of a mature library like JUnit. Code length is appropriate given the API surface and backward-compatibility requirements, with no unnecessary repetition beyond intentional overloads. Action granularity is consistently one action per line, aiding comprehension. Reading flow is natural: static factories first, then instance methods in order of utility. Minor deductions include the concise but less-descriptive field naming convention (f-prefix) and some methods with conditional/logic chains, but these are trivial and idiomatic to the codebase.

Run 3

The code is highly readable and well-structured. It uses a clear class layout with related fields grouped, and methods are logically ordered. Nesting is minimal; conditionals and loops are shallow. Each method has a clear purpose, and naming is descriptive (e.g., fChildren, formatDisplayName). The code length is appropriate—concise while retaining necessary documentation. Action granularity is consistent, with one operation per line in most cases. Reading flow is natural, aided by Javadoc comments that explain intent without being verbose. Minor deductions: some naming conventions (e.g., f-prefixed fields) may feel outdated, and the methodAndClassNamePatternGroupOrDefault method is slightly awkward in naming but still clear. Overall, it is production-quality and easy to follow.

Run 1

1. Code Structure: Well-organized factory methods, constructors, accessors, and helpers; constants and fields appearing midway slightly weaken organization. 2. Nesting: Mostly flat, with early returns and only shallow loop/conditional nesting. 3. Clarity of intent: Descriptive method names and extensive documentation explain the API well; regex group numbers, abbreviated variables, and implicit display-name parsing require extra interpretation. 4. Code length: Individual methods are concise, but repeated factory overloads and lengthy, repetitive Javadocs increase scanning effort. 5. Action granularity: Statements generally perform one action per line; constructor calls and ternary expressions remain manageable. 6. Reading flow: Consistent formatting and small methods support natural reading, though scattered declarations, long lines, and switching between factory methods and instance behavior introduce minor interruptions.

Run 2

Code Structure: Factory methods, constructors, accessors, and helpers are mostly logically grouped, although constants and fields appear after several methods. Nesting: Shallow conditionals, early returns, and simple loops keep control flow easy to follow. Clarity of intent: Descriptive method names and extensive documentation explain the test-description model; legacy field prefixes, numeric regex group references, and implicit display-name parsing slightly obscure details. Code length: Individual methods are concise, but repeated factory overloads and verbose Javadocs increase overall length. Action granularity: Statements generally perform one action per line, with only straightforward expressions combining operations. Reading flow: Consistent formatting and delegation support natural reading, though scattered suite factories, long signatures, and occasional awkward documentation interrupt it. Overall, the code is highly readable with minor organizational and verbosity issues.

Run 3

Code Structure: Factory methods, constructors, accessors, and behavioral methods are logically grouped, although constants and fields interrupt the factory section. Nesting: Mostly flat methods with early returns; loops and conditionals remain shallow. Clarity of intent: Descriptive method names and extensive documentation explain the API well, but numeric regex groups, legacy field prefixes, and subtle identity and class-loading behavior require extra attention. Code length: Individual methods are concise, though repetitive factory overloads and lengthy, sometimes outdated documentation increase scanning effort. Action granularity: Statements generally perform one action per line, with compact expressions remaining understandable. Reading flow: Consistent formatting and small methods support natural reading, but scattered declarations, repetitive comments, and occasional long signatures slightly disrupt flow.