Sample
Schnappinger/junit4/org.junit.ComparisonFailure
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 38.1Δ 5.1 |
| Scalabrino | 0.696 | 0–1; higher is more readable | 37.7Δ 5.6 |
| Dorn | 0.077 | 0–1; higher is more readable | 30.7Δ 12.5 |
| Mi | 0.169 | 0–1; higher is more readable | 13.2Δ 30.0 |
| LLOC | 60 | Logical lines; fewer is more readable | 34.7Δ 8.6 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 23.6 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 12.0 |
| BTTF | 0.349 | 0–1; higher is more readable | 27.1Δ 16.2 |
| Human | 3.75 | 1–4; original rating | 43.2 |
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. | 3914.587 | −129.181 |
| Source linesThe number of non-empty source lines. | 156 | +62.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.471 | −6.706 |
Intercept 8.87 + feature contributions = -64.618 (log-odds).
Score = sigmoid(-64.618) = 0.
| Score | 0.696 |
|---|
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. | 156 | −4.487 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 114 | +3.206 |
| 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. | 153.981 | −2.857 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 114 | −2.195 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 154.871 | +1.755 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 153.974 | +1.68 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.062 | +0.339 |
Intercept 0.07 + feature contributions = -2.489 (log-odds).
Score = sigmoid(-2.489) = 0.077.
| Score | 0.169 |
|---|
| Score | 60 |
|---|
Run 1
The code is well-structured and highly readable. It follows a clean logical organization with a clear separation between the outer exception class and its inner helper class. Nesting is minimal: only one level of nested class plus short, flat methods. The intent is very clear—both the class-level Javadoc and method comments explain the failure-diff formatting logic. Code length is appropriate, with each method focused on a single responsibility. Action granularity is good: most lines perform one operation, and loop constructs are compact but understandable. The reading flow is natural—fields, constructors, public getters, then private helper methods in the order they are used. Minor deductions: the `findCommonSuffix` loop uses two control variables that may require a moment to parse, and `computeCommonSuffix` has a slightly dense condition. Overall, this is exemplary Java code with strong readability.
Run 2
The code is well-structured and readable. The class hierarchy is clear (ComparisonFailure extends AssertionError), fields are logically grouped, and methods are concise with descriptive names. Nesting is minimal, and the inner ComparisonCompactor class cleanly separates string-compaction logic. Clarity of intent is mostly strong due to good Javadoc comments. However, the compactString method relies on substring arithmetic that could be cryptic without careful reading, slightly reducing clarity. Method length is acceptable, and most lines perform one action. Reading flow is natural, but some complexity in computeCommonPrefix/computeCommonSuffix and the loop conditions in findCommonSuffix may require extra attention. Overall, the code is maintainable but could benefit from minor refactoring or additional comments around the substring logic.
Run 3
The code is well-structured, with a clear separation between the exception class and its internal string-compaction logic. It uses a private static nested class to encapsulate helper behavior, which keeps the main class focused. Nesting is minimal and methods are small, single-purpose, and named clearly. Javadoc comments explain intent for both the class and its methods. The private helper methods (findCommonPrefix, findCommonSuffix, computeCommonPrefix, computeCommonSuffix) are logically ordered and each performs one action, aiding readability. The only minor drawbacks are slightly dense string-building logic in computeCommonSuffix and a few long lines, but these do not significantly hinder understanding. Overall, the code is highly readable and maintainable.
Run 1
1. Code Structure: Well organized into an exception class and a dedicated compactor, with focused helper methods. 2. Nesting: Shallow overall; loops contain only simple conditional breaks. 3. Clarity of intent: Descriptive names and documentation explain string comparison and compaction, although context-length comments misleadingly suggest a maximum total string length. Local variables shadow fields, and suffix arithmetic requires careful reading. 4. Code length: Generally concise, though repetitive documentation and a trivial equality wrapper add modest overhead. 5. Action granularity: Mostly one action per line; the suffix loop updates two indices, and long return expressions combine several operations. 6. Reading flow: Compaction proceeds naturally from validation through shared-prefix/suffix detection to formatting. Stateful helper dependencies and dense substring calculations slightly interrupt otherwise clear flow.
Run 2
Code Structure: Well organized, separating the exception interface from string-compaction logic in a nested helper class with focused methods. Nesting: Shallow conditionals and loops keep control flow easy to follow. Clarity of intent: Descriptive names and documentation explain the overall purpose, although prefix/suffix index arithmetic requires careful reading and context-length comments are slightly misleading. Code length: Mostly concise, with some repetitive documentation and a trivial equality helper adding modest verbosity. Action granularity: Most lines perform one clear action; the suffix loop updates two counters, and long substring/concatenation expressions combine several operations. Reading flow: Methods follow a logical progression from comparison to prefix/suffix discovery and formatting. Mutable helper state and local variables shadowing expected/actual fields introduce minor cognitive overhead.
Run 3
Code Structure: Well organized, with the exception API separated from string-compaction logic in a private helper class. Nesting: Shallow control flow; loops contain only simple comparisons, and an early return handles special cases. Clarity of intent: Descriptive method names and documentation explain the purpose, although mutable prefix/suffix state, local variables shadowing fields, and index arithmetic require extra attention. Code length: Methods are short and focused, but some documentation is repetitive. Action granularity: Mostly one action per line; the suffix loop updates two indices, and several return expressions combine multiple operations. Reading flow: Compaction proceeds naturally from validation to finding shared regions and formatting differences. Long substring expressions and implicit dependencies between helper methods slightly interrupt otherwise clear reading.