Sample
Schnappinger/junit4/junit.framework.Assert
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 28.8Δ 48.3 |
| Scalabrino | 0.852 | 0–1; higher is more readable | 75.3Δ 1.7 |
| Dorn | 0.028 | 0–1; higher is more readable | 25.1Δ 52.0 |
| Mi | 0.832 | 0–1; higher is more readable | 98.3Δ 21.3 |
| LLOC | 104 | Logical lines; fewer is more readable | 23.6Δ 53.5 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 3.1 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 3.3 |
| BTTF | 0.53 | 0–1; higher is more readable | 46.5Δ 30.5 |
| Human | 3.96 | 1–4; original rating | 77.1 |
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. | 7855.142 | −259.22 |
| Source linesThe number of non-empty source lines. | 339 | +135.6 |
| 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.449 | −6.674 |
Intercept 8.87 + feature contributions = -121.424 (log-odds).
Score = sigmoid(-121.424) = 0.
| Score | 0.852 |
|---|
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. | 340 | −11.002 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 235 | +7.391 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 236 | −4.995 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 338.93 | +4.328 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 98.976 | +0.792 |
| 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. | 98.976 | −0.527 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.058 | +0.378 |
Intercept 0.07 + feature contributions = -3.565 (log-odds).
Score = sigmoid(-3.565) = 0.028.
| Score | 0.832 |
|---|
| Score | 104 |
|---|
Run 1
The code is highly readable. It follows a clear, consistent structure with each assertion method having overloads for message/no-message variants. Nesting is minimal, with early returns/throws avoiding deep indentation. Method names and Javadoc comments make intent explicit. The code is concise, with straightforward delegation between overloads. Each line generally performs one action, and control flow reads naturally. Minor deductions: slight duplication across primitive type overloads and occasional verbose parameter lists, but these are typical for assertion utility classes and do not meaningfully hinder clarity.
Run 2
The code is highly readable. It is a utility class of assertion methods with a clear, logical structure: a protected constructor, then a sequence of overloaded assertion methods (assertTrue, assertFalse, fail, assertEquals for various types, assertNull, assertNotNull, assertSame, assertNotSame) and helper methods at the end. Nesting is minimal, with early returns reducing indentation. Each method has a single, obvious purpose and is concise; most methods are 1-5 lines. Action granularity is one action per line, making the flow natural. The use of method overloading and delegation (e.g., assertTrue(boolean) calls assertTrue(String, boolean)) keeps the code DRY and easy to follow. Javadoc comments are present and clear, explaining each method's behavior. The only minor drawbacks are the repetitive nature of many overloaded methods (which is inherent to the API) and a slight inconsistency in method ordering (assertNotNull appears before assertNull), but overall the code is exceptionally clear and well-organized.
Run 3
The code is a clear, well-structured legacy JUnit Assert class with consistent formatting and straightforward logic. Organization is logical, grouping related overloaded methods together, and nesting is minimal (usually one level). Intent is clearly documented with Javadoc on every method. Code length is moderate, with some repetitive overloads, but this is typical for assertion APIs. Action granularity is good: each method performs one clear assertion or delegates to another. Reading flow is natural, with method names and parameters following standard conventions. Minor readability drawbacks include repetitive boilerplate across primitive types, slightly overloaded method signatures (e.g., two String-parameter assertEquals overloads), and the deprecated legacy style. Overall, it is easy to read and understand, even for someone unfamiliar with the codebase, but the redundancy prevents a higher score.
Run 1
Code Structure: Assertion methods are logically grouped, related overloads are adjacent, and shared failure helpers reduce duplication. Nesting: Shallow conditionals and early returns keep control flow flat. Clarity of intent: Descriptive method names, consistent parameters, and documentation clearly communicate purpose; negated floating-point comparisons require slightly more attention. Code length: Individual methods are concise, but numerous overloads and repetitive documentation make the class lengthy, largely justified by its API. Action granularity: Each statement generally performs one clear action, with straightforward delegation and no crowded multi-statement lines. Reading flow: Consistent formatting and predictable overload patterns make navigation natural. Minor distractions include inconsistent modifier ordering, reversed overload ordering in some groups, and repeated message-formatting logic.
Run 2
Code Structure: Assertion methods are logically grouped, overloads are adjacent, and shared failure helpers reduce duplication. Nesting: Control flow is shallow, with simple conditionals and early returns. Clarity of intent: Descriptive method and parameter names, supported by Javadoc, make the purpose clear; negated floating-point comparisons require slightly more thought. Code length: Individual methods are concise, but numerous overloads and repetitive documentation make the class lengthy. Action granularity: Lines generally contain a single statement or clear operation, without compressed multi-action code. Reading flow: Consistent formatting and predictable delegation make navigation natural, though inconsistent modifier ordering and occasional differences in overload ordering slightly weaken consistency.
Run 3
Code Structure: Related assertions and their overloads are grouped logically, with shared failure helpers reducing duplication. Nesting: Methods remain flat, using simple conditionals and early returns rather than deep nesting. Clarity of intent: Descriptive method and parameter names, supported by Javadoc, make behavior clear; negated floating-point comparisons require slightly more attention. Code length: Individual methods are concise, although numerous overloads and repetitive documentation make the class lengthy. Action granularity: Statements generally perform one clear action per line, with delegating overloads easy to understand. Reading flow: Consistent formatting and predictable overload patterns support natural scanning, though inconsistent modifier ordering and the reversed overload order in some null checks slightly weaken consistency.