Sample

Schnappinger/junit4/org.junit.internal.runners.statements.Fail

Human rating uses the original dataset scale.

Human3.95
Lines16

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.2670–1; higher is more readable
76.3Δ 6.8
Scalabrino0.9190–1; higher is more readable
93.8Δ 24.4
Dorn0.8280–1; higher is more readable
90.1Δ 20.6
Mi0.6890–1; higher is more readable
80.9Δ 11.4
LLOC5Logical lines; fewer is more readable
83.0Δ 13.5
DeepSeek V4 Pro18.670–20; mean of three runs
98.3Δ 28.9
GPT-6.1 Sol190–20; mean of three runs
92.6Δ 23.1
BTTF0.7250–1; higher is more readable
87.5Δ 18.0
Human3.951–4; original rating
69.5

Views

Source code

package org.junit.internal.runners.statements; import org.junit.runners.model.Statement; public class Fail extends Statement { private final Throwable fError; public Fail(Throwable e) { fError = e; } @Override public void evaluate() throws Throwable { throw fError; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.289.507−9.554
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.485−6.727
Source linesThe number of non-empty source lines.16+6.4

Intercept 8.87 + feature contributions = -1.011 (log-odds).
Score = sigmoid(-1.011) = 0.267.

Score0.919

Feature contributions

FeatureValueContribution
(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.46+1.717
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.17+0.434
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.15.787−0.189
Indentation frequencyHow rapidly indentation changes from line to line.16−0.184
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.084+0.127

Intercept 0.07 + feature contributions = 1.569 (log-odds).
Score = sigmoid(1.569) = 0.828.

Score0.689
Score5
Run 1

The code is highly readable. It has a clear, logical structure with a single-purpose class and constructor. Nesting is effectively flat with minimal indentation. Intent is unambiguous: it represents a failing statement that throws a given error. The class is concise, using only essential fields and methods. Each line performs a single action, enhancing clarity. Reading flow is natural, from field declaration to constructor to evaluate method. One minor point: the field name 'fError' is slightly unconventional (the 'f' prefix suggests fields, common in older Java style), but it does not significantly hinder comprehension.

Run 2

The code is concise and well-structured. It follows the Single Responsibility Principle by creating a dedicated 'Fail' statement that throws a provided error. Naming is descriptive (e.g., 'fError' for the field, 'e' for the constructor parameter). Nesting is minimal, and the reading flow is intuitive — construct with an error, evaluate by throwing it. The only minor deductions are for the use of a prefix 'f' in 'fError', which is a style choice that some may find slightly dated, and the constructor parameter 'e' being less descriptive than it could be. Overall, it is highly readable with clear intent and efficient code length.

Run 3

The code is highly readable, demonstrating excellent structure and clarity. It has a single responsibility, minimal nesting, and clear intent. The class is concise with appropriate action granularity and a natural reading flow. Minor deduction for the slightly obscure field name 'fError' rather than a more descriptive name like 'error' or 'failure'.

Run 1

Code Structure: A clean, focused class with a field, constructor, and overridden method in logical order. Nesting: No nested control flow, making the code easy to scan. Clarity of intent: The class stores a throwable and throws it when evaluated; the name Fail reinforces this purpose. The names fError and e are slightly less descriptive than error or failure. Code length: Minimal, with no unnecessary implementation details. Action granularity: Each statement performs a single action. Reading flow: Natural progression from stored state to initialization to execution, with appropriate spacing and a clear override annotation.

Run 2

Code Structure: Clearly organized into a field, constructor, and overridden method. Nesting: Flat, with no nested control flow. Clarity of intent: The Fail class stores an error and throws it when evaluated; fError and e are slightly less descriptive than error. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one action. Reading flow: Natural progression from stored state to initialization to behavior, supported by conventional formatting and @Override.

Run 3

Code Structure: Clearly organized into a field, constructor, and overridden method. Nesting: Flat, with no nested control flow. Clarity of intent: The Fail class and evaluate method clearly express a statement that throws a stored error; fError and e are slightly less descriptive than modern naming alternatives. Code length: Minimal, with no unnecessary logic. Action granularity: Each statement performs one action. Reading flow: Natural progression from stored state to initialization to execution, supported by conventional formatting.