Sample
Schnappinger/junit4/org.junit.experimental.max.MaxHistory
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 32.4Δ 60.5 |
| Scalabrino | 0.749 | 0–1; higher is more readable | 48.3Δ 44.6 |
| Dorn | 0.319 | 0–1; higher is more readable | 49.8Δ 43.1 |
| Mi | 0.817 | 0–1; higher is more readable | 97.0Δ 4.1 |
| LLOC | 65 | Logical lines; fewer is more readable | 33.2Δ 59.7 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 39.8 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 54.0 |
| BTTF | 0.583 | 0–1; higher is more readable | 54.5Δ 38.4 |
| Human | 4 | 1–4; original rating | 92.9 |
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. | 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.
| Score | 0.749 |
|---|
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. | 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.
| Score | 0.817 |
|---|
| Score | 65 |
|---|
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.