Sample
Schnappinger/junit4/org.junit.internal.runners.TestMethod
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 47.2Δ 39.0 |
| Scalabrino | 0.675 | 0–1; higher is more readable | 32.9Δ 53.3 |
| Dorn | 0.352 | 0–1; higher is more readable | 51.5Δ 34.7 |
| Mi | 0.507 | 0–1; higher is more readable | 34.3Δ 51.8 |
| LLOC | 28 | Logical lines; fewer is more readable | 50.7Δ 35.5 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 59.9Δ 26.2 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 12.4 |
| BTTF | 0.546 | 0–1; higher is more readable | 48.8Δ 37.3 |
| Human | 3.97 | 1–4; original rating | 86.1 |
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. | 2049.041 | −67.618 |
| Source linesThe number of non-empty source lines. | 71 | +28.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.642 | −6.963 |
Intercept 8.87 + feature contributions = -37.311 (log-odds).
Score = sigmoid(-37.311) = 0.
| Score | 0.675 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 67 | +1.58 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 72 | −1.513 |
| 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. | 119.972 | −1.416 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 120 | +1.132 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 67 | −1.117 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 70.835 | +0.58 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.073 |
Intercept 0.07 + feature contributions = -0.61 (log-odds).
Score = sigmoid(-0.61) = 0.352.
| Score | 0.507 |
|---|
| Score | 28 |
|---|
Run 1
The code is well-structured with a clear single responsibility: representing a test method. Methods are short, focused, and named descriptively (e.g., isIgnored, getTimeout, expectsException). Nesting is flat, with no conditional depth beyond one level. Intent is clear throughout the class, and each line performs a single action. The reading flow is natural, moving from simple checks to invocation. Minor deductions: the getExpectedException method could be slightly more concise by returning annotation.expected() directly after the guard clause, and the isUnexpected method will throw a NullPointerException if getExpectedException() returns null, which is a readability/robustness concern. Overall, the code is highly readable and easy to follow.
Run 2
The code is generally clear and well-structured, with small focused methods and minimal nesting. Field naming (fMethod, fTestClass) follows an older convention but is consistent. Most methods have a single clear purpose. However, `getTimeout()` could be simplified (the timeout variable is unnecessary), and `isUnexpected` assumes `getExpectedException()` never returns null, which is a potential runtime issue. The deprecated class and backward-compatibility context reduce clarity slightly. Overall, it is readable but not exceptional due to minor redundancy and a hidden null-risk in exception handling.
Run 3
The code is highly readable with clear, focused methods that each perform a single action. Structure is logical: fields, constructor, query methods, then invocation. Nesting is minimal (only one if-else and one if). Intent is obvious from method names like isIgnored, expectsException, and getBefores. Length is appropriate—no unnecessary verbosity. Action granularity is well-maintained, with each line doing one thing. Reading flow is natural top-to-bottom. Minor improvements could include simplifying getExpectedException’s else branch, but overall this is excellent readability.
Run 1
Code Structure: Well-organized class with small methods separating annotation inspection, lifecycle lookup, and invocation. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: Descriptive method names and explicit types communicate purpose; legacy f-prefixed fields and isUnexpected's implicit requirement that an expected exception exists slightly reduce clarity. Code length: Concise overall, though getTimeout uses an unnecessary temporary variable and getExpectedException has a redundant else after return. Action granularity: Each statement performs a single clear action. Reading flow: Consistent formatting and straightforward delegation make the code easy to follow; the long invoke signature is a minor visual distraction.
Run 2
Code Structure: Well-organized class with small, focused methods and straightforward delegation. Nesting: Minimal nesting; simple conditionals keep control flow easy to follow. Clarity of intent: Descriptive method names and familiar JUnit annotations communicate purpose clearly, though the f-prefixed fields are dated and isUnexpected implicitly requires an expected exception to exist. Code length: Concise overall, with minor redundancy in getTimeout's temporary variable and getExpectedException's unnecessary else after return. Action granularity: Each statement performs a single clear action. Reading flow: Consistent formatting and logical method grouping support natural reading, although the long invoke signature slightly reduces scanability.
Run 3
Code Structure: Well-organized class with small, focused methods separating annotation lookup, lifecycle methods, and invocation. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: Descriptive method names and familiar JUnit annotations make the purpose clear; legacy f-prefixed fields and the implicit requirement that isUnexpected() only run when an exception is expected slightly reduce clarity. Code length: Concise overall, though getTimeout() has an unnecessary local variable and getExpectedException() uses an avoidable else after return. Action granularity: Each statement performs a single clear action. Reading flow: Consistent formatting and straightforward delegation make the code easy to follow, with only the long invoke() declaration mildly interrupting the flow.