Sample
Schnappinger/junit4/org.junit.runners.model.FrameworkField
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 61.9Δ 7.6 |
| Scalabrino | 0.858 | 0–1; higher is more readable | 78.4Δ 9.0 |
| Dorn | 0.823 | 0–1; higher is more readable | 89.1Δ 19.6 |
| Mi | 0.376 | 0–1; higher is more readable | 23.4Δ 46.0 |
| LLOC | 23 | Logical lines; fewer is more readable | 55.9Δ 13.5 |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs | 91.4Δ 21.9 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 92.6Δ 23.1 |
| BTTF | 0.694 | 0–1; higher is more readable | 79.5Δ 10.1 |
| 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. | 1391.167 | −45.909 |
| Source linesThe number of non-empty source lines. | 76 | +30.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.612 | −6.918 |
Intercept 8.87 + feature contributions = -13.557 (log-odds).
Score = sigmoid(-13.557) = 0.
| Score | 0.858 |
|---|
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. | 76 | −1.655 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 63 | +1.442 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 93.987 | +0.712 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 75.705 | +0.648 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 93.935 | −0.314 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.073 | +0.233 |
Intercept 0.07 + feature contributions = 1.535 (log-odds).
Score = sigmoid(1.535) = 0.823.
| Score | 0.376 |
|---|
| Score | 23 |
|---|
Run 1
The code is well-structured and highly readable. It follows a clear logical organization with a single class wrapping a Java reflection Field. The methods are concise, each performing one clear action, and the field is properly encapsulated. The constructor validates input with a meaningful exception. JavaDoc comments on public methods explain the purpose without redundancy. The class naming and inheritance hierarchy are clear. Minor deductions: the `getName()` method unnecessarily delegates to `getField()` instead of directly using `fField`, and the `isShadowedBy()` method compares only by name, which could be slightly confusing without deeper context. Overall, the code demonstrates excellent readability with natural reading flow, shallow nesting, and clear intent throughout.
Run 2
The code is highly readable due to its clear structure, flat nesting, and consistent naming conventions. Each method is concise and performs a single action, which improves comprehension. The class extends FrameworkMember and wraps a Field object, with methods delegating to the underlying field—intent is obvious. Javadoc comments are present for non-obvious methods and the constructor validates input properly. There is no deep nesting or tangled logic. Reading flow follows a logical order: constructor, overrides, public accessors, and utility methods. The only minor deductions are the slightly redundant getField() calls in getName() and toString(), and the lack of an @Override on getAnnotations(), though it implements an abstract method. Overall, the code is clean, well-organized, and easy to follow.
Run 3
The code is highly readable. It has a clear class structure with a single responsibility, wrapping a Field. Nesting is minimal; the only deep indentation is in the constructor's null check, which is acceptable. Intent is clear from method names and Javadoc. Code length is concise, with no unnecessary lines. Action granularity is one action per line. Reading flow is natural, with overrides grouped logically after the constructor. The only minor deductions are for the slightly verbose null check indentation and the unused import of 'Annotation', but these are trivial.
Run 1
Code Structure: A well-organized class with a single responsibility: wrapping a reflective Field. Nesting: Nearly flat, with only a simple constructor null check. Clarity of intent: Descriptive method names, straightforward delegation, and useful documentation make the purpose clear; the legacy name fField is slightly less natural than field. Code length: Concise, with short methods and no unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Consistent formatting and predictable methods make the class easy to follow, though mixing direct fField access with getField() introduces minor stylistic inconsistency.
Run 2
Code Structure: A logically organized wrapper class with small, focused methods and a clear constructor validation step. Nesting: Minimal, with only one shallow conditional. Clarity of intent: Descriptive method names, straightforward delegation, and useful documentation make the purpose clear; the legacy name fField is slightly less natural than field. Code length: Concise, with no unnecessary logic or repetition beyond expected wrapper methods. Action granularity: Each statement performs one action, and methods generally delegate a single operation. Reading flow: Consistent formatting and predictable method bodies make the class easy to scan, although mixing direct fField access with getField() introduces a minor stylistic inconsistency.
Run 3
Code Structure: A logically organized wrapper class with small, focused methods and clear separation of responsibilities. Nesting: Almost entirely flat; only the constructor's null check introduces nesting. Clarity of intent: Method names, straightforward delegation, and targeted Javadoc make the purpose clear, although the legacy name fField is slightly less natural than field. Code length: Concise, with little unnecessary code; the repeated delegation is appropriate for the wrapper. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: Consistent formatting and predictable methods support smooth reading. Minor inconsistencies, such as using getField() in getName() but accessing fField directly elsewhere, slightly reduce uniformity.