Sample
Schnappinger/junit4/org.junit.rules.Stopwatch
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.928 | 0–1; higher is more readable | 88.0Δ 48.9 |
| Scalabrino | 0.854 | 0–1; higher is more readable | 77.4Δ 38.3 |
| Dorn | 0.586 | 0–1; higher is more readable | 66.3Δ 27.2 |
| Mi | 0.457 | 0–1; higher is more readable | 28.4Δ 10.7 |
| LLOC | 35 | Logical lines; fewer is more readable | 47.0Δ 7.9 |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs | 83.0Δ 43.9 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 34.7 |
| BTTF | 0.635 | 0–1; higher is more readable | 64.0Δ 24.9 |
| Human | 3.46 | 1–4; original rating | 39.1 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 174 | +69.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 2091.299 | −69.013 |
| 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.602 | −6.904 |
Intercept 8.87 + feature contributions = 2.553 (log-odds).
Score = sigmoid(2.553) = 0.928.
| Score | 0.854 |
|---|
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. | 175 | −5.16 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 87 | +2.272 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 173.875 | +2.021 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 102.914 | +0.856 |
| 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. | 102.971 | −0.696 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.036 | +0.589 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.349 (log-odds).
Score = sigmoid(0.349) = 0.586.
| Score | 0.457 |
|---|
| Score | 35 |
|---|
Run 1
The code is well-structured with clear separation of public API, protected hooks, and private helpers. Nesting is minimal and flat. Intent is clear through descriptive method names and Javadoc, though the Javadoc example is somewhat long. Action granularity is generally one action per line, but some fields/assignments (e.g., `private long fStartNanos;`) could be spaced better. The naming convention `fStartNanos` is slightly dated and inconsistent with typical Java style, which mildly impacts clarity. Reading flow is natural, though the method `starting()` has the same name as an inner private method and an overridden protected method, which can cause confusion. Overall, the code is highly readable with minor stylistic issues.
Run 2
The code is highly readable. It has a clear logical structure with a comprehensive Javadoc that includes examples. Nesting is minimal, with straightforward method bodies. Intent is obvious: the Stopwatch rule measures test execution time and provides hooks for different outcomes. Code length is appropriate, avoiding unnecessary verbosity while maintaining completeness. Each method generally performs one action, contributing to good action granularity. The reading flow is natural, with clear separation of public API, protected overridable methods, and private helpers. Minor drawbacks include the redundant `starting()` method (which overrides a final method and simply calls a private method of the same name) and the slight inconsistency in how `finished` is handled compared to `succeeded`/`failed`/`skipped` (which call `stopping`). Overall, the code is exemplary in readability.
Run 3
The code is well-structured, with a clear class hierarchy and logical grouping of related methods. The Javadoc examples significantly aid comprehension. Methods are concise and focused on a single action. Nesting is minimal; the only deep nesting appears in the included example (a separate usage scenario). Intent is explicit via descriptive method names like 'starting', 'stopping', 'succeeded', 'failed', etc. The code avoids redundancy by delegating to private helpers. The reading flow follows a natural progression from public API to private utilities. Minor deductions: the 'fStartNanos'/'fEndNanos' prefix is slightly dated, and the 'succeeded(Description)' override final methods could benefit from a brief comment distinguishing them from the overloaded callbacks. Overall, highly readable.
Run 1
Code Structure: Well-organized class with distinct runtime access, extension hooks, conversion utilities, and lifecycle overrides, although related overloads are separated. Nesting: Almost entirely flat, with short methods and no complex branching. Clarity of intent: Descriptive method names and documentation clearly communicate test timing behavior; overloaded lifecycle names and prefixed fields introduce minor ambiguity. Code length: Implementation is concise, but extensive examples and repetitive callback wrappers increase reading length. Action granularity: Statements generally perform one action per line, making state updates and callback delegation easy to follow. Reading flow: Consistent method patterns provide predictable flow, though tracing lifecycle behavior requires jumping between overrides and helpers. Unconventional modifier ordering and assignment spacing slightly reduce polish.
Run 2
Code Structure: Well organized into timing state, extension hooks, conversion utilities, and lifecycle overrides, although grouping related overloads could improve navigation. Nesting: Almost entirely flat, with short methods and no complex branching. Clarity of intent: Descriptive method names and documented callbacks make the purpose clear; prefixed fields and overloaded lifecycle methods add minor cognitive overhead. Code length: Implementation is concise, though extensive examples and repetitive wrappers increase overall length. Action granularity: Statements generally perform one action per line, and lifecycle overrides clearly separate stopping from notification. Reading flow: Consistent formatting and straightforward delegation support natural reading, but unconventional modifier ordering, assignment spacing, and similarly named helper methods slightly interrupt the flow.
Run 3
Code Structure: Well organized into timing state, extension callbacks, conversion utilities, and lifecycle overrides, though grouping related overloads could improve navigation. Nesting: Almost entirely flat, with short methods and no complex control flow. Clarity of intent: Descriptive method names and Javadoc clearly explain the stopwatch and callback API; prefixed field names and overloaded lifecycle methods add minor friction. Code length: Implementation is concise, although extensive examples and repetitive callback wrappers increase overall length. Action granularity: Statements generally perform one action per line, making timing updates and callback dispatch easy to follow. Reading flow: Consistent formatting and straightforward methods support natural reading, but unusual modifier ordering, annotation placement, and inconsistent spacing around assignments slightly reduce polish.