Sample
Schnappinger/junit4/org.junit.experimental.max.MaxCore
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 32.1Δ 11.8 |
| Scalabrino | 0.744 | 0–1; higher is more readable | 47.3Δ 3.4 |
| Dorn | 0.158 | 0–1; higher is more readable | 38.0Δ 5.9 |
| Mi | 0.092 | 0–1; higher is more readable | 10.2Δ 33.7 |
| LLOC | 59 | Logical lines; fewer is more readable | 35.3Δ 8.6 |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs | 38.0Δ 5.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 11.4 |
| BTTF | 0.395 | 0–1; higher is more readable | 33.3Δ 10.6 |
| Human | 3.79 | 1–4; original rating | 43.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. | 5402.875 | −178.295 |
| Source linesThe number of non-empty source lines. | 181 | +72.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.601 | −6.901 |
Intercept 8.87 + feature contributions = -103.926 (log-odds).
Score = sigmoid(-103.926) = 0.
| Score | 0.744 |
|---|
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. | 181 | −5.372 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 135 | −2.677 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 179.901 | +2.105 |
| 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. | 109.972 | −0.993 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.972 | +0.97 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.294 |
Intercept 0.07 + feature contributions = -1.671 (log-odds).
Score = sigmoid(-1.671) = 0.158.
| Score | 0.092 |
|---|
| Score | 59 |
|---|
Run 1
The code has good structure with clear separation of concerns and generally follows one-action-per-line. The class-level Javadoc is excellent, and method-level documentation helps intent. However, readability is hindered by nested anonymous classes (constructLeafRequest), complex string manipulation for malformed JUnit 3 tests, and magic strings scattered throughout. The sortRequest method has a cryptic comment about 'karma points' instead of clear reasoning. findLeaves recursion is reasonably clear, but the special-case handling within it adds cognitive load. Naming is mostly good, though 'each' is used instead of more descriptive names. Overall, the code is maintainable but requires careful reading in several spots due to legacy workarounds and non-obvious conditions.
Run 2
The code is generally well-structured and readable. It uses clear method names, appropriate JavaDoc comments, and maintains a logical flow from public API methods to private helper methods. The class-level documentation explains the sorting algorithm clearly. Methods are concise and focused on single responsibilities. The nesting is shallow, mostly limited to one or two levels. However, a few aspects reduce readability: the comment 'We'll pay big karma points for this' is cryptic and assumes inside knowledge; the anonymous inner class in constructLeafRequest adds complexity; and some string comparison logic (e.g., checking for 'TestSuite with 0 tests') relies on magic strings. The buildRunner method has multiple conditional returns which, while flat, requires careful reading to follow all paths. Overall, the code is maintainable but could benefit from extracting constants and simplifying the runner construction logic.
Run 3
The code is generally well-structured with clear separation of concerns and good use of method extraction. The class-level documentation clearly explains the sorting algorithm. Methods are concise and focused on single responsibilities. However, readability suffers from several issues: the field naming convention (fHistory) is outdated Hungarian notation that reduces clarity; there's excessive Javadoc for trivial methods like run() overloads; some methods mix levels of abstraction (buildRunner has deeply nested conditionals with embedded comments); magic strings like 'TestSuite with 0 tests' and 'warning(junit.framework.TestSuite$1)' obscure intent; and the anonymous inner class in constructLeafRequest disrupts reading flow. The nested conditional logic in findLeaves could be flatter. While the overall architecture is sound, these details prevent higher readability. The code would benefit from replacing magic strings with constants and simplifying the buildRunner method's branching structure.
Run 1
Code Structure: Well-organized methods separate execution, sorting, runner construction, and leaf discovery. Nesting: Most methods are flat with early returns; anonymous classes and recursive traversal introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation explain the sorting strategy, but generic variables such as 'each', string-based special cases, and the vague 'karma points' comment reduce clarity. Code length: Reasonably concise for its responsibilities, although repeated documentation and anonymous-class boilerplate add bulk. Action granularity: Statements generally perform one action per line; a few chained calls and nested constructor expressions require extra parsing. Reading flow: Public entry points lead naturally into supporting helpers, with consistent formatting and sensible delegation. Legacy JUnit compatibility handling interrupts the otherwise straightforward flow.
Run 2
Code Structure: Well organized into small methods separating execution, sorting, runner construction, and leaf traversal. Nesting: Mostly shallow with early returns; anonymous classes and recursive traversal introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation explain the purpose and ordering rules, but string-based detection of special JUnit cases, generic names like 'each', and the vague karma comment reduce clarity. Code length: Reasonably concise for its responsibilities, although repeated documentation and compatibility handling add bulk. Action granularity: Statements generally perform one action per line; a few chained calls and nested constructor expressions require additional parsing. Reading flow: Public entry points naturally lead into helper methods, and formatting is consistent. Legacy edge cases and anonymous runner construction slightly interrupt an otherwise straightforward flow.
Run 3
Code Structure: Well-organized, focused methods separate execution, sorting, runner construction, and tree traversal. Nesting: Mostly shallow with early returns; anonymous classes and recursive leaf handling introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation clearly explain test prioritization, but generic names like 'each', string-based special cases, and the cryptic karma comment reduce clarity. Code length: Generally concise; overloads provide useful delegation, although repeated documentation adds some bulk. Action granularity: Most lines perform one clear action; a few chained calls and nested constructor expressions require additional parsing. Reading flow: Public entry points lead naturally into implementation helpers, with consistent formatting. Legacy JUnit compatibility branches and anonymous runner construction slightly interrupt the otherwise straightforward flow.