Sample
Schnappinger/junit4/org.junit.Assume
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.999 | 0–1; higher is more readable | 91.6Δ 14.6 |
| Scalabrino | 0.925 | 0–1; higher is more readable | 94.9Δ 17.8 |
| Dorn | 0.266 | 0–1; higher is more readable | 45.5Δ 31.5 |
| Mi | 0.135 | 0–1; higher is more readable | 11.9Δ 65.2 |
| LLOC | 21 | Logical lines; fewer is more readable | 58.4Δ 18.6 |
| 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.687 | 0–1; higher is more readable | 77.6Δ 0.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) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 157 | +62.8 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 1738.634 | −57.375 |
| 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.622 | −6.933 |
Intercept 8.87 + feature contributions = 7.362 (log-odds).
Score = sigmoid(7.362) = 0.999.
| Score | 0.925 |
|---|
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. | 156 | −4.487 |
| 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. | 140.975 | −2.306 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 156.923 | +1.784 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 140.981 | +1.47 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 61 | +1.373 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.027 | +0.681 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -1.017 (log-odds).
Score = sigmoid(-1.017) = 0.266.
| Score | 0.135 |
|---|
| Score | 21 |
|---|
Run 1
The code is highly readable with a clear, logical structure. It begins with focused static imports, followed by comprehensive Javadoc that explains intent and usage examples. The class is organized into small, single-purpose methods, resulting in flat code with minimal nesting. Method names and parameters clearly express their actions, and each non-doc line generally performs one action. The reading flow is natural, from general assumptions to more specific variants (e.g., with messages or no exceptions). Minor limitations include some repetitive Javadoc and slightly verbose documentation, but these do not detract from overall clarity.
Run 2
The code is well-structured, with clear Javadoc explanations and logical organization. Methods are short, focused, and delegate cleanly to core logic (e.g., assumeThat). There is minimal nesting—only one level in condition checks—and each method performs a single action, improving granularity. Static imports are used thoughtfully to enhance readability, and the reading flow is natural, following a consistent pattern from simple boolean assumptions to matcher-based and exception-based assumptions. Minor deductions are for some repetitive Javadoc examples and the slightly dense import block, but overall clarity of intent is high.
Run 3
The code is highly readable. Structure is logical: class-level Javadoc explains purpose, methods are grouped by functionality, and each public method has concise documentation. Nesting is minimal, with only single-level conditionals. Intent is clear due to descriptive method names (assumeTrue, assumeFalse, assumeNotNull, assumeNoException) and consistent delegation to assumeThat. Code length is appropriate—no unnecessary verbosity or duplication. Action granularity is mostly one action per line, though some single-line if-throw statements slightly reduce readability. Reading flow is natural: overloaded methods follow a logical progression, and imports are organized. Minor deductions include some Javadoc examples being verbose and single-line conditional throws, but overall the code is well-organized and easy to understand.
Run 1
Code Structure: Methods are logically grouped by assumption type, with related overloads adjacent and shared behavior delegated to helper methods. Nesting: Very shallow; conditionals contain only a single throw. Clarity of intent: Descriptive method names and extensive Javadoc make the API purpose clear, though parameter names such as b and e are terse. Code length: Implementations are concise, but duplicated documentation for assumeThat overloads adds unnecessary length. Action granularity: Almost every line performs one action; the inline if-and-throw statement is a minor formatting inconsistency. Reading flow: Consistent formatting and predictable method organization support natural reading, with small documentation issues such as malformed example markup and a missing message parameter description slightly reducing polish.
Run 2
Code Structure: Methods are logically grouped by assumption type, with overloads adjacent and shared behavior delegated to helper methods. Nesting: Control flow is flat, with at most one conditional level. Clarity of intent: Descriptive method names and extensive documentation clearly explain behavior; parameter names such as b and e are less descriptive. Code length: Implementations are concise, although duplicated Javadoc for assumeThat overloads adds unnecessary length. Action granularity: Most lines contain a single action; the inline if-and-throw statement slightly reduces consistency and scanability. Reading flow: Consistent formatting, static imports, and predictable method organization make the class easy to follow. Minor documentation formatting defects and inconsistent conditional formatting prevent a perfect score.
Run 3
Code Structure: Well-organized utility class with related methods and overloads grouped together; delegation avoids tangled logic. Nesting: Nearly flat, with only simple conditional checks. Clarity of intent: Descriptive method names and extensive documentation clearly explain assumptions and failure behavior, although parameter names b and e are terse. Code length: Implementations are concise, but duplicated assumeThat documentation and lengthy examples add unnecessary bulk. Action granularity: Most statements perform one action per line; the inline if-and-throw statement is a minor inconsistency. Reading flow: Consistent formatting, static imports, and predictable method grouping support natural reading, slightly interrupted by repetitive documentation and minor documentation formatting defects.