Sample
Schnappinger/junit4/org.junit.internal.builders.IgnoredBuilder
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.003 | 0–1; higher is more readable | 69.2Δ 0.2 |
| Scalabrino | 0.678 | 0–1; higher is more readable | 33.2Δ 36.3 |
| Dorn | 0.696 | 0–1; higher is more readable | 75.9Δ 6.4 |
| Mi | 0.5 | 0–1; higher is more readable | 34.0Δ 35.5 |
| LLOC | 4 | Logical lines; fewer is more readable | 87.0Δ 17.5 |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs | 96.0Δ 26.6 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 92.6Δ 23.1 |
| BTTF | 0.719 | 0–1; higher is more readable | 85.5Δ 16.0 |
| Human | 3.95 | 1–4; original rating | 69.5 |
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. | 418.764 | −13.819 |
| 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.491 | −6.737 |
| Source linesThe number of non-empty source lines. | 15 | +6 |
Intercept 8.87 + feature contributions = -5.686 (log-odds).
Score = sigmoid(-5.686) = 0.003.
| Score | 0.678 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 60 | +1.124 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 15 | +0.505 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 13.656 | −0.219 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 15 | −0.218 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.1 | −0.025 |
Intercept 0.07 + feature contributions = 0.831 (log-odds).
Score = sigmoid(0.831) = 0.696.
| Score | 0.5 |
|---|
| Score | 4 |
|---|
Run 1
The code is highly readable. It follows a clear, logical structure with a single responsibility: checking for an @Ignore annotation and returning an appropriate Runner. Nesting is minimal (one if statement). Intent is obvious from the method and class names. The code is concise without being cryptic. Each line performs a single logical action, and the reading flow is natural: check condition, return result, return fallback.
Run 2
The code is highly readable due to its clear, single-purpose method. The class structure is logical with a simple, flat conditional that avoids unnecessary nesting. Intent is immediately obvious from the method and class names. The code is concise with no extraneous logic or comments needed. Each action—checking the annotation, returning a runner, and returning null—is on its own line, improving clarity. The reading flow is natural, following a simple if-return pattern. The only minor deduction is the lack of a default or explicit null-return comment, but this is idiomatic. Overall, it is a textbook example of clean, maintainable code.
Run 3
The code is highly readable. It has a clear single responsibility: building a runner for ignored test classes. The structure is logical with a single method that checks for the @Ignore annotation. Nesting is minimal with only one if statement. The intent is obvious from class and method names. The code is concise with no unnecessary lines. Each action is on its own line, and the reading flow follows a natural pattern: check condition, return result, fall back to null. The only minor deduction is the implicit null return at the end, which slightly reduces clarity of intent compared to an explicit else block, but this is a common Java pattern that doesn't significantly impact readability.
Run 1
Code Structure: A single, logically organized override handles ignored test classes. Nesting: Only one shallow conditional, making control flow easy to follow. Clarity of intent: Descriptive class and method names, plus the explicit Ignore annotation check, clearly communicate the purpose; the meaning of returning null depends on the RunnerBuilder contract. Code length: Concise with no unnecessary logic. Action granularity: Each statement performs one action on its own line. Reading flow: Imports, class declaration, annotation check, and return paths appear in a natural order.
Run 2
Code Structure: Imports, class declaration, and a single focused method are logically organized. Nesting: Only one conditional level, making control flow easy to follow. Clarity of intent: Names and the Ignore annotation check clearly communicate that ignored test classes receive an IgnoredClassRunner; returning null is slightly less explicit without framework context. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one action on its own line. Reading flow: The annotation check, runner creation, and fallback return form a natural top-to-bottom sequence.
Run 3
Code Structure: Clearly organized class with a single focused method. Nesting: Only one conditional level, making control flow easy to follow. Clarity of intent: Descriptive names and the Ignore annotation check clearly communicate the purpose; returning null relies on the RunnerBuilder contract rather than explaining the fallback explicitly. Code length: Concise without unnecessary logic or boilerplate. Action granularity: Each statement performs one action. Reading flow: Natural progression from checking whether the class is ignored to returning the appropriate runner or null.