Sample
Schnappinger/junit4/org.junit.internal.runners.statements.Fail
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.267 | 0–1; higher is more readable | 76.3Δ 6.8 |
| Scalabrino | 0.919 | 0–1; higher is more readable | 93.8Δ 24.4 |
| Dorn | 0.828 | 0–1; higher is more readable | 90.1Δ 20.6 |
| Mi | 0.689 | 0–1; higher is more readable | 80.9Δ 11.4 |
| LLOC | 5 | Logical lines; fewer is more readable | 83.0Δ 13.5 |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs | 98.3Δ 28.9 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 92.6Δ 23.1 |
| BTTF | 0.725 | 0–1; higher is more readable | 87.5Δ 18.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. | 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.
| Score | 0.919 |
|---|
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. | 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.
| Score | 0.689 |
|---|
| Score | 5 |
|---|
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.