Sample

Schnappinger/junit4/org.junit.experimental.max.MaxHistory

Human rating uses the original dataset scale.

Human4
Lines170

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
32.4Δ 60.5
Scalabrino0.7490–1; higher is more readable
48.3Δ 44.6
Dorn0.3190–1; higher is more readable
49.8Δ 43.1
Mi0.8170–1; higher is more readable
97.0Δ 4.1
LLOC65Logical lines; fewer is more readable
33.2Δ 59.7
DeepSeek V4 Pro16.330–20; mean of three runs
53.1Δ 39.8
GPT-6.1 Sol160–20; mean of three runs
38.9Δ 54.0
BTTF0.5830–1; higher is more readable
54.5Δ 38.4
Human41–4; original rating
92.9

Views

Source code

package org.junit.experimental.max; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; import java.util.Comparator; import java.util.HashMap; import java.util.Map; import org.junit.runner.Description; import org.junit.runner.Result; import org.junit.runner.notification.Failure; import org.junit.runner.notification.RunListener; /** * Stores a subset of the history of each test: * <ul> * <li>Last failure timestamp * <li>Duration of last execution * </ul> */ public class MaxHistory implements Serializable { private static final long serialVersionUID = 1L; /** * Loads a {@link MaxHistory} from {@code file}, or generates a new one that * will be saved to {@code file}. */ public static MaxHistory forFolder(File file) { if (file.exists()) { try { return readHistory(file); } catch (CouldNotReadCoreException e) { e.printStackTrace(); file.delete(); } } return new MaxHistory(file); } private static MaxHistory readHistory(File storedResults) throws CouldNotReadCoreException { try { FileInputStream file = new FileInputStream(storedResults); try { ObjectInputStream stream = new ObjectInputStream(file); try { return (MaxHistory) stream.readObject(); } finally { stream.close(); } } finally { file.close(); } } catch (Exception e) { throw new CouldNotReadCoreException(e); } } private final Map<String, Long> fDurations = new HashMap<String, Long>(); private final Map<String, Long> fFailureTimestamps = new HashMap<String, Long>(); private final File fHistoryStore; private MaxHistory(File storedResults) { fHistoryStore = storedResults; } private void save() throws IOException { ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream( fHistoryStore)); stream.writeObject(this); stream.close(); } Long getFailureTimestamp(Description key) { return fFailureTimestamps.get(key.toString()); } void putTestFailureTimestamp(Description key, long end) { fFailureTimestamps.put(key.toString(), end); } boolean isNewTest(Description key) { return !fDurations.containsKey(key.toString()); } Long getTestDuration(Description key) { return fDurations.get(key.toString()); } void putTestDuration(Description description, long duration) { fDurations.put(description.toString(), duration); } private final class RememberingListener extends RunListener { private long overallStart = System.currentTimeMillis(); private Map<Description, Long> starts = new HashMap<Description, Long>(); @Override public void testStarted(Description description) throws Exception { starts.put(description, System.nanoTime()); // Get most accurate // possible time } @Override public void testFinished(Description description) throws Exception { long end = System.nanoTime(); long start = starts.get(description); putTestDuration(description, end - start); } @Override public void testFailure(Failure failure) throws Exception { putTestFailureTimestamp(failure.getDescription(), overallStart); } @Override public void testRunFinished(Result result) throws Exception { save(); } } private class TestComparator implements Comparator<Description> { public int compare(Description o1, Description o2) { // Always prefer new tests if (isNewTest(o1)) { return -1; } if (isNewTest(o2)) { return 1; } // Then most recently failed first int result = getFailure(o2).compareTo(getFailure(o1)); return result != 0 ? result // Then shorter tests first : getTestDuration(o1).compareTo(getTestDuration(o2)); } private Long getFailure(Description key) { Long result = getFailureTimestamp(key); if (result == null) { return 0L; // 0 = "never failed (that I know about)" } return result; } } /** * @return a listener that will update this history based on the test * results reported. */ public RunListener listener() { return new RememberingListener(); } /** * @return a comparator that ranks tests based on the JUnit Max sorting * rules, as described in the {@link MaxCore} class comment. */ public Comparator<Description> testComparator() { return new TestComparator(); } }

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.5250.418−173.264
Source linesThe number of non-empty source lines.170+68
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.452−6.678

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

Score0.749

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.171−5.018
Indentation frequencyHow rapidly indentation changes from line to line.148+4.382
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.149−2.998
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.169.884+1.965
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.84.947+0.566
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.075+0.21
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.84.965+0.066

Intercept 0.07 + feature contributions = -0.757 (log-odds).
Score = sigmoid(-0.757) = 0.319.

Score0.817
Score65
Run 1

The code is well-structured with clear separation of concerns, using a Serializable class to manage test history. The Javadoc and method names clearly convey intent. Most methods are concise and follow a natural reading flow. Nesting is generally shallow, though the readHistory method has a try-within-try-within-try pattern that slightly increases complexity. The RememberingListener and TestComparator inner classes are logically placed and readable. Action granularity is mostly good, though a few lines combine multiple actions (e.g., ObjectOutputStream construction). The comment inside testStarted about 'most accurate possible time' is slightly awkward but not major. Overall, the code is readable, maintainable, and avoids excessive length or unnecessary complexity.

Run 2

The code is generally well-structured with clear class organization: static factory methods, field declarations, then public API methods. Nested classes are separated at the bottom, improving readability. The nesting depth is mostly flat (2-3 levels), except in readHistory where triple try-with-resources creates slight depth. Variable naming with 'f' prefix for fields is consistent but unconventional. Methods are concise and single-purpose. Reading flow is natural. Minor issues: the CouldNotReadCoreException class isn't shown but referenced, some line-wrapping could be cleaner, and the inline comment in the middle of a ternary statement breaks visual flow. The 'f' prefix requires reader acclimation. Comments are helpful where present. Overall, readable but could benefit from modern Java try-with-resources and removal of field prefix conventions.

Run 3

The code is well-structured and readable. It has clear class organization with logical grouping of methods (static factory, serialization, getters/setters, inner classes). Nesting is generally flat except for the 'readHistory' method's nested try-finally blocks for resource cleanup, which is acceptable given the Java version constraints. Intent is well-documented through Javadoc and method names. Code length is appropriate - no unnecessary verbosity. Action granularity is good with mostly one action per line, though some lines like the comment in 'testStarted' break flow slightly. Reading flow is natural: fields at top, then methods in logical order, inner classes at bottom. The only readability issues are minor: the nested resource management in 'readHistory' could be simpler with try-with-resources, and the ternary with comment in 'getTestDuration' comparison is slightly awkward. Overall, this is production-quality, maintainable code that clearly communicates its purpose.

Run 1

Code Structure: Responsibilities are logically separated into persistence methods, history accessors, a listener, and a comparator, though placing fields after static methods slightly disrupts organization. Nesting: Most methods are flat, but readHistory uses deeply nested try/finally blocks that increase reading effort. Clarity of intent: Documentation and sorting comments explain the purpose well; legacy f-prefixed fields, generic comparator parameters, and the name forFolder for a file parameter reduce clarity. Code length: Generally concise, with short, focused methods, although resource-management boilerplate adds verbosity. Action granularity: Statements typically perform one action per line; nested stream construction is a minor exception. Reading flow: The overall flow is coherent, but the comment embedded in a multiline ternary and the awkwardly split timing comment interrupt it.

Run 2

Code Structure: Persistence, history access, event handling, and sorting are separated into focused methods and inner classes. Nesting: Most methods are flat, but readHistory uses several nested try/finally blocks that complicate reading. Clarity of intent: Descriptive method names, documentation, and sorting comments explain the purpose well; prefixed field names, generic comparator parameters, and the misleading forFolder name reduce clarity slightly. Code length: Generally concise, although resource-management boilerplate adds avoidable length. Action granularity: Statements typically perform one action per line, with only minor complexity in chained expressions. Reading flow: The organization is mostly natural, but the comment embedded in the comparator's ternary expression and the split timing comment interrupt the flow.

Run 3

Code Structure: Persistence, history access, event handling, and sorting are separated into focused methods and inner classes. Nesting: Most code is flat, but readHistory has several nested try/finally blocks that complicate reading. Clarity of intent: Descriptive method names, documentation, and sorting comments explain the purpose well; forFolder naming, f-prefixed fields, and generic comparator parameters are less clear. Code length: Generally concise, though resource-management boilerplate adds avoidable length. Action granularity: Statements mostly perform one action per line, with only minor complexity from chained calls. Reading flow: Organization is coherent, but the comment embedded in the comparator's ternary expression and the awkwardly split timing comment interrupt otherwise natural flow.