Sample
Schnappinger/junit4/org.junit.internal.runners.JUnit38ClassRunner
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 24.1Δ 17.5 |
| Scalabrino | 0.722 | 0–1; higher is more readable | 43.5Δ 1.9 |
| Dorn | 0.267 | 0–1; higher is more readable | 45.9Δ 4.3 |
| Mi | 0.588 | 0–1; higher is more readable | 57.4Δ 15.8 |
| LLOC | 89 | Logical lines; fewer is more readable | 26.9Δ 14.7 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 25.2 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 48.0Δ 6.4 |
| BTTF | 0.462 | 0–1; higher is more readable | 41.3Δ 0.3 |
| Human | 3.72 | 1–4; original rating | 41.6 |
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. | 7678.99 | −253.407 |
| Source linesThe number of non-empty source lines. | 180 | +72 |
| 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.341 | −6.511 |
Intercept 8.87 + feature contributions = -179.048 (log-odds).
Score = sigmoid(-179.048) = 0.
| Score | 0.722 |
|---|
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. | 175 | +5.316 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 175 | −3.595 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 179.926 | +2.105 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 92.972 | +0.696 |
| 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. | 92.917 | −0.27 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.093 | +0.041 |
Intercept 0.07 + feature contributions = -1.01 (log-odds).
Score = sigmoid(-1.01) = 0.267.
| Score | 0.588 |
|---|
| Score | 89 |
|---|
Run 1
The code is generally well-structured with clear separation of concerns, minimal nesting, and good use of descriptive method names. The listener adapter class is well-encapsulated, and the delegation patterns are straightforward. However, readability is slightly reduced by the empty catch blocks in getAnnotations, the somewhat convoluted conditional chain in makeDescription, and the mixed concern of the filter method needing to handle both Filterable and TestSuite cases. The blanket catch blocks silently swallowing exceptions also hurt intent clarity. Overall, the code is readable but could benefit from refactoring the getAnnotations method and the makeDescription branch logic.
Run 2
The code is well-structured and readable. It uses clear class and method names, follows consistent formatting, and maintains a logical separation of concerns. The JUnit38ClassRunner class is focused, delegating to helper methods and inner classes appropriately. Nesting is mostly shallow; the longest method (makeDescription) uses a clear if-else chain rather than deep nesting. Intent is generally clear, though some legacy naming (e.g., fNotifier, fTest) and the dual constructor approach require minor inference. Code length is reasonable, with concise one-action-per-line style. The reading flow is natural, moving from high-level run logic down to utility methods. Minor deductions: the getAnnotations method has empty catch blocks, and the createSuiteDescription logic is slightly dense. Overall, this is production-quality, maintainable code.
Run 3
The code is highly readable. It is well-structured, with clear separation of concerns between methods and a logical organization. Nesting is minimal and well-controlled; the deepest constructs are simple if-else chains rather than deeply nested blocks. Intent is clear: the class adapts JUnit 3.8 tests to the JUnit 4 Runner API, and method names reflect that purpose. Code length is appropriate, neither too verbose nor excessively terse. Action granularity is mostly one action per line, except for a few one-line if statements, which remain clear. Reading flow is natural, with private helper methods placed logically near their usage, though the `makeDescription` method is slightly long but still easy to follow. The only minor blemish is the empty `catch` blocks in `getAnnotations`, but this is a common pattern for reflection. Overall, the code is well-organized, self-explanatory, and maintainable.
Run 1
Code Structure: Responsibilities are logically separated into a listener adapter and focused methods for execution, descriptions, filtering, and sorting. Nesting: Generally shallow, though filtering contains a loop and nested condition, and description generation uses a lengthy type-dispatch chain. Clarity of intent: Method names clearly communicate purpose; abbreviated variables (tc, ts, n, m), legacy field prefixes, and unexplained empty exception handlers reduce clarity. Code length: Mostly concise, with some trivial wrappers and repeated type checks adding minor verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Consistent formatting and cohesive methods support natural reading, although the nested class appears before the runner's main functionality, and recursive description handling requires some backtracking.
Run 2
Code Structure: Well-organized methods separate listener adaptation, description generation, filtering, and sorting; the nested listener keeps related behavior together. Nesting: Generally shallow, although filtering combines conditional branches, a loop, and an inner condition. Clarity of intent: Descriptive method names and familiar JUnit types communicate purpose, but abbreviated variables, legacy f-prefixed fields, and unexplained empty catch blocks reduce clarity. Code length: Mostly concise, with some minor verbosity from trivial wrappers, repeated getTest() calls, and explicit casts. Action granularity: Statements generally perform one action per line; a few chained calls and ternary expressions modestly increase reading effort. Reading flow: Execution and delegation are easy to follow, though the lengthy instanceof chain in makeDescription and inconsistent import grouping slightly interrupt the flow.
Run 3
Code Structure: Well-organized methods separate listener adaptation, description creation, filtering, and sorting; the nested listener encapsulates related behavior. Nesting: Generally shallow, although filtering combines branching, iteration, and a conditional, and description creation uses a lengthy type-dispatch chain. Clarity of intent: Descriptive method names make the runner's purpose clear; abbreviated variables such as tc, ts, n, and m, legacy f-prefixed fields, and unexplained empty catch blocks reduce clarity. Code length: Mostly concise, with small focused methods, though trivial wrappers and repeated type checks add some verbosity. Action granularity: Statements generally perform one action per line, with only occasional compound expressions. Reading flow: Consistent formatting and cohesive methods support natural reading, but imports are not cleanly grouped, related description helpers are split between classes, and repeated casts slightly interrupt the flow.